fix: PDF preview viewer broken on sign page

[saquibreja7-hash]

Summary

• Preview PDF routes served Buffer.buffer, which for small (<8KB) buffers is Node's shared 8KB pool with a non-zero byte offset — so the response contained garbage bytes around the PDF and the iframe viewer on the sign page failed to render.
• Fixed preview-notice and preview-hash-advisory to copy into an exact-sized Uint8Array.

Testing

• npm run type-check and full npm run test (293 passed) via pre-push hook.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
meri-asmita	Ready	Preview, Comment	Jul 12, 2026 12:43pm

[claude]

Review: PDF preview buffer fix

Reviewed the diff (2 files, 4 lines changed) plus the surrounding notice-generation and dispatch code.

What it does: Replaces pdfBytes.buffer as ArrayBuffer with new Uint8Array(pdfBytes) in both preview-notice and preview-hash-advisory GET routes.

Why this matters beyond a cosmetic fix: generateNoticePdf() returns Buffer.from(await pdfDoc.save()) (notice-pdf.ts:169). For buffers under Node's pool threshold, Buffer.from() allocates from Node's shared internal memory pool, and .buffer returns the entire underlying pool ArrayBuffer rather than a slice scoped to this Buffer's byteOffset/length. Serving that raw ArrayBuffer as the HTTP response body could leak adjacent pool bytes — in a worst case, fragments of another concurrently-processed PDF (another case's notice body, reference number, or hash annex) — into an unrelated survivor's PDF response. In this NCII platform that's a real cross-tenant data-exposure risk, not just a rendering glitch. new Uint8Array(pdfBytes) correctly copies only the buffer's logical contents into a freshly-sized ArrayBuffer, closing that gap.

Verified no regressions:

• Checked other generateNoticePdf call sites (sign-notice, sign-hash-advisory) — they use Buffer.from(pdfBytes).toString("base64"), which already copies by the Buffer's logical length rather than exposing .buffer, so they were never affected.
• Grepped the codebase for any other .buffer as ArrayBuffer pattern — none remain.
• No safety-gate, auth, encryption, or dispatch logic is touched; both routes' existing ENABLE_HASH_UPLOAD, requireSession, getCaseForUser, and legal-review gate checks are untouched.

No issues found. This is a minimal, correct, and worthwhile fix.