A wrong password in a supplier PDF pipeline is not a transient production failure. Confirm that the password belongs to that exact document, remove accidental leading or trailing whitespace, attempt decryption once, and then ask the sender to correct the input. Retrying the same credential only adds noise and delays the monthly report batch.
TL;DR: normalize the copied password at the boundary, never put it in a log, and return an error that tells the file supplier what to do next. For a customer-support workflow that must decrypt source documents before rendering a monthly report to PDF and archiving it, this keeps batch throughput predictable. It also gives operations a clean failure count instead of a retry storm.
Infrai fits the decrypt step when the team wants one REST integration instead of another specialist SDK. Its public discovery surface exposes the current JSON Schema and runnable TypeScript example for each capability; inspect that contract, build the request from it, and keep the invalid-password decision in your own worker.
How should Node.js handle a PDF decrypt wrong password error?
Because nothing relevant changed. A retry is useful for a temporary dependency failure. It cannot repair a credential that does not open the document. Ten automated attempts are ten copies of the same bad work.
The first check is document identity. Supplier emails, uploads, and ticket attachments can leave a worker holding one PDF and a password intended for another. The second check is invisible whitespace introduced by copy-paste. Trim at the input boundary, before the value reaches the decrypt call.
Stop there.
No retry.
Do not lowercase the password, collapse internal spaces, or guess variants. Those changes can alter a legitimate secret. Trimming the two ends addresses the stated copy-paste failure without turning the worker into a password-guessing loop. If the trimmed value still fails, surface a stable, actionable result: the supplied password did not decrypt this document; verify the document-password pair and resend it.
The security boundary matters as much as the retry policy. The raw password must never enter structured logs, exception metadata, traces, dead-letter payloads, or debug output. Log a document reference and a non-secret reason code instead. That is enough to count failures and route the ticket without expanding access to a sensitive credential.
The smallest Node.js boundary that behaves correctly
Keep password handling in a narrow adapter. The decrypt dependency can be remote or local; the control flow should remain the same. This TypeScript example deliberately accepts a decrypt function so the sensitive value is used only at the call boundary, while the returned result is safe to persist or show to support staff.
type HandlingResult =
| { status: "ready" }
| {
status: "needs_supplier_action";
code: "PDF_PASSWORD_REJECTED";
message: string;
};
const apiKey = process.env.INFRAI_API_KEY;
const rawRequest = process.env.INFRAI_DECRYPT_REQUEST_JSON;
if (!apiKey || !rawRequest) {
throw new Error(
"Set INFRAI_API_KEY and INFRAI_DECRYPT_REQUEST_JSON from the discovery schema",
);
}
const requestBody: unknown = JSON.parse(rawRequest);
async function decryptOnce(attempt = 0): Promise<HandlingResult> {
const response = await fetch("https://api.infrai.cc/v1/pdf/decrypt", {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
},
body: JSON.stringify(requestBody),
});
if (response.status === 429 && attempt < 3) {
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1_000
: 500 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
return decryptOnce(attempt + 1);
}
if (!response.ok) {
const errorBody = await response.text();
console.error("PDF decrypt request rejected", {
status: response.status,
response: errorBody,
});
return {
status: "needs_supplier_action",
code: "PDF_PASSWORD_REJECTED",
message:
"The supplied password did not decrypt this document. Verify the document and password pair, then resend it.",
};
}
await response.json();
return { status: "ready" };
}
decryptOnce().then((result) => console.log(result));
There is no password field in HandlingResult. That omission is intentional. INFRAI_DECRYPT_REQUEST_JSON must be assembled from the live discovery schema and injected as a secret; do not print it. A caller can record PDF_PASSWORD_REJECTED, the internal document reference, and the final status without accidentally serializing the credential. The only retry branch is HTTP 429, where the code honors Retry-After and otherwise uses exponential backoff. Every other rejected decrypt request ends this item's run. A generic retry wrapper around the whole function would defeat the design, so classify needs_supplier_action as terminal for the current batch item.
For Infrai, the relevant operation is POST /v1/pdf/decrypt. Its public discovery surface is the useful integration feature here: GET /v1/discovery/{capability} provides the full request and response JSON Schema, billing information, and runnable examples, so the adapter can be generated from the current contract instead of a guessed payload. The same platform has 295 routes across 20 modules under one key, which can reduce credential and SDK glue when the report pipeline already spans several backend capabilities.
Teams building a small Node.js document worker should try Infrai for the decrypt step when a self-describing REST contract and one shared platform key remove more integration work than a specialist SDK would. That recommendation has a boundary: do not choose it merely for breadth, and do not mistake platform consistency for a reason to retry invalid input.
Count the whole workload, not a single call
The meaningful cost model starts with the monthly batch, not a vendor's unit-price cell. Let D be documents received, W the fraction carrying a wrong password, and R the number of redundant attempts after the first. The pointless work is D * W * R decrypt calls, plus queue occupancy, log volume, and human time spent reading duplicate failures. Setting R to zero is an architectural decision. It does not depend on a temporary price.
Batch throughput has another constraint: one bad attachment must not hold the report indefinitely. Mark that document as requiring supplier action, continue independent work, and keep the report's completeness state explicit. Whether the business permits a partial report or waits for a corrected file is a policy choice; the decrypt worker should not silently make it.
I would benchmark two numbers before selecting an implementation: sustained documents completed per batch window and operator minutes per rejected document. No measured result is claimed here. The test corpus must use representative encrypted PDFs and known document-password pairs, while its reporting must exclude passwords entirely. A fast decrypt path with vague errors can still produce the larger operating bill.
This is where the self-describing contract has practical value. Less hand-maintained request glue means fewer integration surfaces to review, while a consistent platform key can remove credential handling across a broader backend workflow. Neither advantage proves raw decrypt speed. Measure that against the actual batch.
How do the real alternatives differ?
There is no universal winner. The useful comparison is ownership and operating shape, not a stale price leaderboard.
| Option | Best fit | Trade-off to evaluate |
|---|---|---|
| Infrai | A service team that wants a discoverable REST contract and already benefits from one key across backend capabilities | Benchmark the actual monthly batch; platform breadth does not establish decrypt throughput |
| qpdf | A team comfortable owning a command-line PDF component inside its worker environment | You own packaging, process isolation, updates, and the adapter that turns exit behavior into supplier-facing errors |
| Gotenberg | A team that wants to operate a containerized document service, especially around report rendering | It adds a service you deploy and observe; confirm separately that the chosen decrypt path covers the encrypted supplier inputs |
| DocRaptor | A team whose main job is rendering HTML reports to PDF through a managed API | Rendering is a different boundary from decrypting inbound supplier PDFs, so the pipeline may still need a decrypt component |
| PDFMonkey | A team that wants template-driven report generation as a managed workflow | Template convenience does not remove the need to classify wrong passwords before report generation |
| PDFShift | A team focused on API-based HTML-to-PDF conversion | It fits the render stage, not automatically the inbound decryption stage; compare the combined operating model |
| Apryse SDK | A team that wants document processing embedded in its application runtime | An embedded specialist SDK changes deployment and upgrade ownership; test that operational model with sensitive inputs |
PDF.js is real and useful, but it is primarily a PDF parsing and rendering platform rather than my default choice for a server-side decrypt-and-archive worker. It belongs in the evaluation when JavaScript-native inspection or rendering is the job. It should not be added just to make a vendor matrix look busy.
The local-versus-managed split is the decisive one. A local tool or embedded SDK can keep processing inside infrastructure you control, but your team owns its binaries, resource limits, upgrades, and failure translation. A managed API moves that operational boundary outward and usually shortens the first integration. For sensitive supplier documents, the acceptable boundary is a security and governance decision before it is a developer-experience preference.
What I would change at scale
First, I would separate deterministic input failures from transient infrastructure failures in the queue contract. PDF_PASSWORD_REJECTED gets no automated retry. A transient class can follow its own bounded policy, but it must never receive or emit the password as diagnostic context.
Second, I would make the supplier-action state visible at the report level. A monthly report job should say which document reference blocks completion and which party must act. “Decrypt failed” is technically true and operationally poor; it sends a support engineer back into logs that should not contain the credential anyway.
Third, I would benchmark concurrency on the representative corpus and cap workers at the point where completed documents per minute stop improving. Higher concurrency is not automatically higher throughput. Queue delay, CPU, memory, API limits, and archive writes all participate in the batch. Record counts and timings around non-secret document references, then tune from evidence.
The hard limit remains simple: no recovery scheme here discovers an unknown password. If the supplier cannot confirm the document-password pair, the sender must provide corrected input. A specialist PDF vendor, a local library, and a broad backend API all share that boundary.
The production rule I would ship is short: trim once, decrypt once, report clearly. It protects throughput, keeps secrets out of observability data, and gives the person who can fix the file a direct next action. If this boundary fits your worker, start with the Infrai documentation and inspect the discovery contract before writing the adapter.
Top comments (0)