E-Advice PDF Response Troubleshooting

1. Identify the expected response contract

Confirm whether the caller expects raw PDF bytes, Base64-encoded text, XML or JSON that contains a document field, a file reference, or a multipart response. A valid response for one contract is invalid for another.

• Expected content type and character encoding
• Whether compression or Base64 is part of the application contract
• Whether middleware unwraps an envelope before the PDF parser runs
• Expected success and error response schemas

2. Inspect the first bytes or characters safely

A raw PDF normally begins with the PDF signature. HTML, XML, JSON, plain text, or an upstream error page has a different prefix. Capture only a short redacted prefix and response metadata; do not publish the document or customer data.

Base64 text commonly beginning with JVBERi0 is encoded content, not a PDF file ready for a PDF parser. It must be decoded according to the application contract before the resulting bytes are interpreted as a PDF.

3. Separate HTTP framing from application parsing

A missing Content-Length header is not automatically an error. HTTP can frame a response with chunked transfer encoding or by closing the connection, and a conforming HTTP client normally removes that transport framing before passing the body to the application.

Investigate HTTP headers when they conflict with the contract—for example an HTML content type for a document endpoint, unexpected content encoding, a gateway status, or a partial transfer. Do not treat ordinary chunked framing as PDF corruption.

4. Look for an upstream error masquerading as document content

Authentication failures, proxy pages, application exceptions, load-balancer messages, and JSON error envelopes may arrive on the same route as a successful document. Record the HTTP or messaging status, content type, prefix, correlation value, and the first upstream error.

5. Validate document generation independently

If the response contract and transport are correct, prove whether the document service produced a complete PDF before the integration layer handled it. Check generation status, output size, temporary-file or stream completion, metadata, and the hand-off to the next component. Use a synthetic test document where possible.

6. Treat messaging limits as explicit platform behaviour

MQ and other brokers have message-size limits, but an oversized document does not generically become a silently truncated PDF. Depending on product, API, and options, a put or get can fail, return a reason code, or report explicit truncation behaviour. Capture the platform result and configured limit instead of inferring silent loss.

• Message or payload size at each boundary
• Configured maximum message or frame size
• Put, get, channel, gateway, or client return codes
• Whether an application buffer or conversion step imposed a smaller limit

Symptom-to-stage guide

Evidence and privacy checklist

• Correlation value and timestamp range with timezone
• Expected response contract and actual content type
• Short redacted prefix or hexadecimal signature
• Status and return codes at each transport boundary
• Payload sizes before and after encoding or middleware transformation
• Document-generation status and first application error

Remove account numbers, names, addresses, credentials, full documents, and message payloads. For a structured escalation, use the T24 incident evidence checklist.

Related reading