Stream PDF cover render via FPDF_LoadCustomDocument (bookshelf-qwvg) #1010

Merged

zombor merged 2 commits from bd-bookshelf-qwvg into main 2026-07-08 01:24:31 +00:00

Conversation 2 Commits 2 Files changed 4 +496 -164

zombor commented 2026-07-08 00:41:52 +00:00

Owner

Copy link

Summary

• Switch ExtractCoverFromFile PDF path from io.ReadAll (buffer whole file) to streaming io.ReadSeeker via go-pdfium's FileReader/FileReaderSize fields — maps to FPDF_LoadCustomDocument callback reads
• Remove the maxPDFBytes (200MB) rejection guard that was blocking cover extraction on large PDFs like the 233MB "Shattered Nation" game book
• Add renderPDFCoverFromReader + renderPDFPage0FromReader streaming path with same pool/instance/deadline structure as the existing byte-slice path
• Add 7 streaming-render test Describe blocks (pool/instance/deadline/corrupt/zero-page/render-fail/encode-fail) exercising all new branches
• Add countingReaderAt + bytes-read proof test empirically confirming pdfium reads far fewer bytes than total file size for multi-page PDFs
• 100% coverage maintained, no exclusions added

Test plan

• make test — all packages pass
• make coverage — internal/files 100.0%
• make lint (files package) — 0 issues
• Bytes-read proof: 3-page PDF with large pages 1/2 (400×600 JPEG) — pdfium reads << fileSize when rendering page 0
• All 7 error-path Describe blocks pass (pool, instance, deadline, corrupt, zero-page, render, encode)
• readSeekerAt "buffer larger than remaining" truncation branch covered

Closes bead bookshelf-qwvg on merge.

## Summary - Switch `ExtractCoverFromFile` PDF path from `io.ReadAll` (buffer whole file) to streaming `io.ReadSeeker` via go-pdfium's `FileReader`/`FileReaderSize` fields — maps to `FPDF_LoadCustomDocument` callback reads - Remove the `maxPDFBytes` (200MB) rejection guard that was blocking cover extraction on large PDFs like the 233MB "Shattered Nation" game book - Add `renderPDFCoverFromReader` + `renderPDFPage0FromReader` streaming path with same pool/instance/deadline structure as the existing byte-slice path - Add 7 streaming-render test Describe blocks (pool/instance/deadline/corrupt/zero-page/render-fail/encode-fail) exercising all new branches - Add `countingReaderAt` + bytes-read proof test empirically confirming pdfium reads far fewer bytes than total file size for multi-page PDFs - 100% coverage maintained, no exclusions added ## Test plan - [x] `make test` — all packages pass - [x] `make coverage` — `internal/files` 100.0% - [x] `make lint` (files package) — 0 issues - [x] Bytes-read proof: 3-page PDF with large pages 1/2 (400×600 JPEG) — pdfium reads << fileSize when rendering page 0 - [x] All 7 error-path Describe blocks pass (pool, instance, deadline, corrupt, zero-page, render, encode) - [x] `readSeekerAt` "buffer larger than remaining" truncation branch covered Closes bead bookshelf-qwvg on merge.

zombor added 1 commit 2026-07-08 00:41:52 +00:00

feat(files): stream PDF cover render via FPDF_LoadCustomDocument (bookshelf-qwvg) ... f216fc4b0a

Switch ExtractCoverFromFile's PDF path from io.ReadAll (buffer-the-whole-file)
to a streaming io.ReadSeeker approach using go-pdfium's FileReader/FileReaderSize
fields, which maps to FPDF_LoadCustomDocument's callback-based reads.

This unblocks cover extraction on large PDFs (e.g. 233MB game books) that
previously failed with ErrCoverTooLarge because the 200MB buffer cap rejected
the file before pdfium even ran.

Key changes:
- Add renderPDFCoverFromReader + renderPDFPage0FromReader (parallel to the
  existing renderPDFCover/renderPDFPage0 byte-slice path, with the same
  pool/instance/deadline/channel structure)
- Add pdfRenderPage0ReaderFn seam + SetPdfSimpleRenderPage0ReaderForTest export
- ExtractCoverFromFile .pdf case: build io.NewSectionReader(f, 0, size) and
  call the streaming render path; remove the maxPDFBytes rejection guard
- Add 7 streaming-render Describe blocks covering pool/instance/deadline/corrupt/
  zero-page/render-fail/encode-fail error paths via ExtractCoverFromFile
- Add countingReaderAt + makeMultiPagePDF + bytes-read proof test asserting
  pdfium reads far fewer bytes than total file size (empirically confirms
  FPDF_LoadCustomDocument reads on demand, not buffer-all)
- Add readSeekerAt "buffer larger than remaining" truncation test (100% coverage)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

zombor commented 2026-07-08 00:53:57 +00:00

Author

Owner

Copy link

Security Review — PR #1010 (bookshelf-qwvg)

Central question: is removing the 200 MB maxPDFBytes cap from the PDF cover-extraction path safe?

Bounds audit

The original cap comment said pdfium reads the whole document; a crafted PDF could cause unbounded allocation. The PR replaces that single file-size gate with four independent hard bounds that together cover the same threat surface:

1. WASM 1 GB linear-memory cap (pdfiumMaxMemoryPages = 16 384 × 64 KB)
Set on the pool at init time via WithMemoryLimitPages. Any compressed-stream decompression bomb — giant XRef table, huge flate/LZW page stream — is hard-killed when the WASM allocator hits 1 GB. This directly addresses the original threat the comment described, and does so regardless of on-disk file size.

2. 60 s render deadline + WithCloseOnContextDone(true) interrupt
renderPDFCoverFromReader applies context.WithTimeout(ctx, pdfRenderTimeout) before spawning the goroutine. The pool is configured with WithCloseOnContextDone(true), so calling inst.Close() in the ctx.Done() branch immediately interrupts in-flight WASM execution. A pathological PDF that makes pdfium loop indefinitely (crafted circular XRef, adversarial linearisation hint stream, etc.) is killed at 60 s. The goroutine is then drained with <-ch before renderPDFCoverFromReader returns — no goroutine leak, no pool-slot leak.

3. 1 200 × 1 800 pixel raster cap (maxPDFRenderWidth / maxPDFRenderHeight)
RenderPageInPixels is called with these constants on both the buffered and streaming paths. A PDF whose MediaBox declares a physically enormous page (e.g. 1 m × 1 m at 300 DPI) is scaled by pdfium to fit within 1 200 × 1 800 — at most ~8.6 MB of RGBA. Output raster size is not proportional to file size or declared page dimensions.

4. MaxTotal=1 pool serialises rendering
Only one WASM instance ever exists (MaxTotal: 1). Concurrent PDF render requests queue and wait up to pdfiumInstanceTimeout (30 s) for the one slot; beyond that they return a transient error. A flood of adversarially large PDFs cannot trigger parallel memory amplification — at most one render runs at a time, bounded by bounds 1–3 above.

Pool-slot release correctness (no leak on deadline)

renderPDFCoverFromReader structure (new):

• Success branch: closeInstance(inst) before returning result.
• Timeout branch: closeInstance(inst) to signal WASM interruption, then <-ch to drain the goroutine, then return ErrNoCover.

This is structurally identical to the pre-existing renderPDFCover (buffered path) and its deadline test coverage carries over via the new SetPdfSimpleRenderPage0ReaderForTest seam. No goroutine leak, no pool-slot leak.

io.SectionReader / io.ReadSeeker adapter

io.NewSectionReader(f, 0, size) satisfies io.ReadSeeker natively (stdlib). FileReaderSize = size is the actual declared file size passed in by the caller, not a request-supplied value — correct. Negative or zero size causes SectionReader.Read to return EOF immediately, which causes OpenDocument to fail and return ErrNoCover (PERMANENT). No allocation happens in the adapter layer.

Remaining call sites of the old extractPDFCover (buffered path)

extractPDFCover is still called by ExtractCover(fileExt string, data []byte) at cover_extract.go:309. That function takes already-buffered bytes from callers that are separately responsible for any size limit; the file-size cap removal does not affect it.

---

Findings

[MINOR] internal/files/cover_extract_test.go:2858 — bytes-read proof assertion is fragile against pdfium read-pattern changes

The test asserts bytesRead < fileSize using a countingReaderAt that tallies every byte returned by ReadAt (including repeated/overlapping reads). The test comment acknowledges that for small PDFs pdfium's random-access pattern can produce a read total exceeding the file size, which is why pages 1 and 2 are made artificially large (400 × 600 JPEG). The assertion therefore relies on the current ratio of page-0 content to total file size holding across pdfium WASM updates. If an upstream release changes its XRef or hint-stream prefetch strategy, the assertion could flip from < to >= and become a CI flake. Consider either (a) asserting a more generous bound (e.g., < fileSize * 2 / 3 with a comment explaining why) or (b) treating this as a doc-only sanity check that logs the ratio without a hard Expect, since the security claim rests on the WASM memory cap and the deadline — not on the read-count proof.

---

Conclusion on cap removal safety: YES — the 200 MB file-size gate is safely replaced by the four bounds above (1 GB WASM memory, 60 s deadline + WASM interrupt, 1 200 × 1 800 raster cap, MaxTotal=1 pool serialisation). No unbounded memory allocation vector remains on the streaming path. The claim in the updated maxPDFBytes comment and the ExtractCoverFromFile doc comment is accurate.

REVIEW VERDICT: 0 blocker, 0 major, 1 minor

## Security Review — PR #1010 (bookshelf-qwvg) **Central question: is removing the 200 MB `maxPDFBytes` cap from the PDF cover-extraction path safe?** ### Bounds audit The original cap comment said pdfium reads the whole document; a crafted PDF could cause unbounded allocation. The PR replaces that single file-size gate with four independent hard bounds that together cover the same threat surface: **1. WASM 1 GB linear-memory cap (`pdfiumMaxMemoryPages = 16 384` × 64 KB)** Set on the pool at init time via `WithMemoryLimitPages`. Any compressed-stream decompression bomb — giant XRef table, huge flate/LZW page stream — is hard-killed when the WASM allocator hits 1 GB. This directly addresses the original threat the comment described, and does so regardless of on-disk file size. **2. 60 s render deadline + `WithCloseOnContextDone(true)` interrupt** `renderPDFCoverFromReader` applies `context.WithTimeout(ctx, pdfRenderTimeout)` before spawning the goroutine. The pool is configured with `WithCloseOnContextDone(true)`, so calling `inst.Close()` in the `ctx.Done()` branch immediately interrupts in-flight WASM execution. A pathological PDF that makes pdfium loop indefinitely (crafted circular XRef, adversarial linearisation hint stream, etc.) is killed at 60 s. The goroutine is then drained with `<-ch` before `renderPDFCoverFromReader` returns — no goroutine leak, no pool-slot leak. **3. 1 200 × 1 800 pixel raster cap (`maxPDFRenderWidth / maxPDFRenderHeight`)** `RenderPageInPixels` is called with these constants on both the buffered and streaming paths. A PDF whose MediaBox declares a physically enormous page (e.g. 1 m × 1 m at 300 DPI) is scaled by pdfium to fit within 1 200 × 1 800 — at most ~8.6 MB of RGBA. Output raster size is not proportional to file size or declared page dimensions. **4. MaxTotal=1 pool serialises rendering** Only one WASM instance ever exists (`MaxTotal: 1`). Concurrent PDF render requests queue and wait up to `pdfiumInstanceTimeout` (30 s) for the one slot; beyond that they return a transient error. A flood of adversarially large PDFs cannot trigger parallel memory amplification — at most one render runs at a time, bounded by bounds 1–3 above. ### Pool-slot release correctness (no leak on deadline) `renderPDFCoverFromReader` structure (new): - Success branch: `closeInstance(inst)` before returning result. - Timeout branch: `closeInstance(inst)` to signal WASM interruption, then `<-ch` to drain the goroutine, then return `ErrNoCover`. This is structurally identical to the pre-existing `renderPDFCover` (buffered path) and its deadline test coverage carries over via the new `SetPdfSimpleRenderPage0ReaderForTest` seam. No goroutine leak, no pool-slot leak. ### io.SectionReader / io.ReadSeeker adapter `io.NewSectionReader(f, 0, size)` satisfies `io.ReadSeeker` natively (stdlib). `FileReaderSize = size` is the actual declared file size passed in by the caller, not a request-supplied value — correct. Negative or zero `size` causes `SectionReader.Read` to return EOF immediately, which causes `OpenDocument` to fail and return ErrNoCover (PERMANENT). No allocation happens in the adapter layer. ### Remaining call sites of the old `extractPDFCover` (buffered path) `extractPDFCover` is still called by `ExtractCover(fileExt string, data []byte)` at cover_extract.go:309. That function takes already-buffered bytes from callers that are separately responsible for any size limit; the file-size cap removal does not affect it. --- ### Findings [MINOR] internal/files/cover_extract_test.go:2858 — bytes-read proof assertion is fragile against pdfium read-pattern changes The test asserts `bytesRead < fileSize` using a `countingReaderAt` that tallies every byte returned by `ReadAt` (including repeated/overlapping reads). The test comment acknowledges that for small PDFs pdfium's random-access pattern can produce a read total exceeding the file size, which is why pages 1 and 2 are made artificially large (400 × 600 JPEG). The assertion therefore relies on the current ratio of page-0 content to total file size holding across pdfium WASM updates. If an upstream release changes its XRef or hint-stream prefetch strategy, the assertion could flip from `<` to `>=` and become a CI flake. Consider either (a) asserting a more generous bound (e.g., `< fileSize * 2 / 3` with a comment explaining why) or (b) treating this as a doc-only sanity check that logs the ratio without a hard `Expect`, since the security claim rests on the WASM memory cap and the deadline — not on the read-count proof. --- **Conclusion on cap removal safety:** YES — the 200 MB file-size gate is safely replaced by the four bounds above (1 GB WASM memory, 60 s deadline + WASM interrupt, 1 200 × 1 800 raster cap, MaxTotal=1 pool serialisation). No unbounded memory allocation vector remains on the streaming path. The claim in the updated `maxPDFBytes` comment and the `ExtractCoverFromFile` doc comment is accurate. REVIEW VERDICT: 0 blocker, 0 major, 1 minor

zombor commented 2026-07-08 00:57:23 +00:00

Author

Owner

Copy link

CODE REVIEW: NOT APPROVED

Reviewed diff only; did not re-run tests (CI is the source of behavioral truth per .claude/rules/review-standard.md).

---

Phase 0 — no DEMO block check

Not applicable: this is a pure refactor/optimization bead reviewed on diff.

---

Phase 1 — Streaming Correctness (all pass)

• io.NewSectionReader(f, 0, size) → implements io.ReadSeeker ✓
• FileReader: reader, FileReaderSize: size → correct FPDF_LoadCustomDocument API ✓
• Page index 0 rendered (Index: 0) ✓
• maxPDFRenderWidth / maxPDFRenderHeight caps preserved in renderPDFPage0FromReader ✓
• pdfRenderTimeout context deadline applied in renderPDFCoverFromReader ✓
• Pool get → instance → goroutine → closeInstance pattern identical to renderPDFCover ✓
• maxPDFBytes constant not dead: used by pdf_metadata.go:36, library/scan/meta.go, wfengine/llm_scan_workflow.go ✓
• ErrCoverTooLarge not dead: still used by audio/CBX paths ✓
• pdf_page_images.go untouched; scan path takes []byte, still buffered, LLM caller still limits via io.LimitReader(..., files.MaxPDFBytes) ✓
• SetPdfSimpleRenderPage0ReaderForTest seam consistent with existing SetPdfSimpleRenderPage0ForTest pattern ✓

---

Findings

[MAJOR] internal/files/cover_extract.go:596-600 — transient ReadAt I/O errors misclassified as PERMANENT via ErrNoCover

renderPDFPage0FromReader wraps all OpenDocument failures with ErrNoCover:

if err != nil {
    // Corrupt / password-protected / structurally invalid PDF — PERMANENT.
    return nil, fmt.Errorf("pdf: open: %w", errors.Join(err, ErrNoCover))
}

OpenDocument fails both for structurally corrupt PDFs and for transient ReadAt I/O errors (NFS disconnect, disk error mid-read) that occur inside the FPDF_LoadCustomDocument callback. Pdfium cannot distinguish the two failure modes, and neither can this code.

The old code correctly separated them:

data, readErr := io.ReadAll(&readSeekerAt{r: f, size: size})
if readErr != nil {
    return nil, fmt.Errorf("pdf: read: %w", readErr)  // NOT ErrNoCover — retryable
}
return extractPDFCover(context.Background(), data)  // ErrNoCover only on PDF parse failure

Concrete impact: ErrNoCover reaches internal/cover/generate.go:165 where it is treated as "book has no cover" (skip + enqueue fallback template), and wfengine/cover_workflow.go:112 (isPermanentCoverErr) wraps it in gowf.NewPermanentError. An NFS disconnect during the FPDF callback therefore permanently assigns the book a fallback/template cover with no retry — the real cover is lost until the workflow is manually re-triggered. On DISK_TYPE=NETWORK setups this is a real operational regression.

The test change at cover_extract_test.go:2739 ("PDF with a ReadAt failure") now asserts errors.Is(err, files.ErrNoCover) for an injected ReadAt failure — explicitly endorsing the misclassification.

Suggested fix: track ReadAt errors separately via a thin wrapper passed to OpenDocument. After OpenDocument fails, if the wrapper recorded a non-nil ReadAt error, return that error without ErrNoCover so the activity remains retryable.

---

[MINOR] internal/files/cover_extract.go:1111-1144 + internal/files/export_test.go:112-114 — readSeekerAt is now dead production code

The only production instantiation of readSeekerAt (&readSeekerAt{r: f, size: size} inside ExtractCoverFromFile) was deleted by this PR. The type remains defined, its export shim NewReadSeekerAt remains in export_test.go, and this PR adds a new branch test ("Read with buffer larger than remaining bytes") that exercises dead code. All three should be deleted.

---

[MINOR] internal/files/cover_extract_test.go "bytes-read proof" — assertion is weaker than stated claim

The assertion:

Expect(bytesRead).To(BeNumerically("<", fileSize))

claims to prove pdfium reads "far fewer bytes than file size," but the fixture uses solid-color 400×600 JPEG images. Solid-color images compress to near-zero AC DCT coefficients; at quality 75 each 400×600 image is likely 1–3 KB in practice, making the total 3-page PDF perhaps 8–15 KB. Pdfium's FPDF_LoadCustomDocument makes overlapping ReadAt calls (the counter counts bytes, not unique byte ranges), so the margin between bytesRead and fileSize may be thin.

The assertion should express the intent quantitatively (e.g., < fileSize/2) to be a meaningful streaming proof, and the fixture images should use non-uniform content (e.g., random noise via rand.Read or a gradient) to guarantee genuine byte-bulk in pages 1 and 2.

Note: CI is green so the test passes with the current pdfium version, but the proof is weaker than claimed.

---

Verdict

REVIEW VERDICT: 0 blocker, 1 major, 2 minor

The major blocks merge: the ReadAt I/O error → ErrNoCover misclassification is a silent retry-semantic regression that will permanently misflag books on network filesystems.

**CODE REVIEW: NOT APPROVED** Reviewed diff only; did not re-run tests (CI is the source of behavioral truth per `.claude/rules/review-standard.md`). --- ## Phase 0 — no DEMO block check Not applicable: this is a pure refactor/optimization bead reviewed on diff. --- ## Phase 1 — Streaming Correctness (all pass) - `io.NewSectionReader(f, 0, size)` → implements `io.ReadSeeker` ✓ - `FileReader: reader, FileReaderSize: size` → correct FPDF_LoadCustomDocument API ✓ - Page index 0 rendered (`Index: 0`) ✓ - `maxPDFRenderWidth` / `maxPDFRenderHeight` caps preserved in `renderPDFPage0FromReader` ✓ - `pdfRenderTimeout` context deadline applied in `renderPDFCoverFromReader` ✓ - Pool get → instance → goroutine → closeInstance pattern identical to `renderPDFCover` ✓ - `maxPDFBytes` constant not dead: used by `pdf_metadata.go:36`, `library/scan/meta.go`, `wfengine/llm_scan_workflow.go` ✓ - `ErrCoverTooLarge` not dead: still used by audio/CBX paths ✓ - `pdf_page_images.go` untouched; scan path takes `[]byte`, still buffered, LLM caller still limits via `io.LimitReader(..., files.MaxPDFBytes)` ✓ - `SetPdfSimpleRenderPage0ReaderForTest` seam consistent with existing `SetPdfSimpleRenderPage0ForTest` pattern ✓ --- ## Findings [MAJOR] `internal/files/cover_extract.go:596-600` — transient ReadAt I/O errors misclassified as PERMANENT via ErrNoCover `renderPDFPage0FromReader` wraps **all** `OpenDocument` failures with `ErrNoCover`: ```go if err != nil { // Corrupt / password-protected / structurally invalid PDF — PERMANENT. return nil, fmt.Errorf("pdf: open: %w", errors.Join(err, ErrNoCover)) } ``` `OpenDocument` fails both for structurally corrupt PDFs **and** for transient ReadAt I/O errors (NFS disconnect, disk error mid-read) that occur inside the FPDF_LoadCustomDocument callback. Pdfium cannot distinguish the two failure modes, and neither can this code. The old code correctly separated them: ```go data, readErr := io.ReadAll(&readSeekerAt{r: f, size: size}) if readErr != nil { return nil, fmt.Errorf("pdf: read: %w", readErr) // NOT ErrNoCover — retryable } return extractPDFCover(context.Background(), data) // ErrNoCover only on PDF parse failure ``` Concrete impact: `ErrNoCover` reaches `internal/cover/generate.go:165` where it is treated as "book has no cover" (skip + enqueue fallback template), and `wfengine/cover_workflow.go:112` (`isPermanentCoverErr`) wraps it in `gowf.NewPermanentError`. An NFS disconnect during the FPDF callback therefore permanently assigns the book a fallback/template cover with no retry — the real cover is lost until the workflow is manually re-triggered. On `DISK_TYPE=NETWORK` setups this is a real operational regression. The test change at `cover_extract_test.go:2739` ("PDF with a ReadAt failure") now asserts `errors.Is(err, files.ErrNoCover)` for an injected ReadAt failure — explicitly endorsing the misclassification. Suggested fix: track ReadAt errors separately via a thin wrapper passed to `OpenDocument`. After `OpenDocument` fails, if the wrapper recorded a non-nil ReadAt error, return that error without `ErrNoCover` so the activity remains retryable. --- [MINOR] `internal/files/cover_extract.go:1111-1144` + `internal/files/export_test.go:112-114` — `readSeekerAt` is now dead production code The only production instantiation of `readSeekerAt` (`&readSeekerAt{r: f, size: size}` inside `ExtractCoverFromFile`) was deleted by this PR. The type remains defined, its export shim `NewReadSeekerAt` remains in `export_test.go`, and this PR **adds a new branch test** ("Read with buffer larger than remaining bytes") that exercises dead code. All three should be deleted. --- [MINOR] `internal/files/cover_extract_test.go` "bytes-read proof" — assertion is weaker than stated claim The assertion: ```go Expect(bytesRead).To(BeNumerically("<", fileSize)) ``` claims to prove pdfium reads "far fewer bytes than file size," but the fixture uses solid-color 400×600 JPEG images. Solid-color images compress to near-zero AC DCT coefficients; at quality 75 each 400×600 image is likely 1–3 KB in practice, making the total 3-page PDF perhaps 8–15 KB. Pdfium's FPDF_LoadCustomDocument makes overlapping ReadAt calls (the counter counts bytes, not unique byte ranges), so the margin between `bytesRead` and `fileSize` may be thin. The assertion should express the intent quantitatively (e.g., `< fileSize/2`) to be a meaningful streaming proof, and the fixture images should use non-uniform content (e.g., random noise via `rand.Read` or a gradient) to guarantee genuine byte-bulk in pages 1 and 2. Note: CI is green so the test passes with the current pdfium version, but the proof is weaker than claimed. --- ## Verdict ``` REVIEW VERDICT: 0 blocker, 1 major, 2 minor ``` The major blocks merge: the ReadAt I/O error → ErrNoCover misclassification is a silent retry-semantic regression that will permanently misflag books on network filesystems.

zombor referenced this pull request from a commit 2026-07-08 01:08:23 +00:00

fix(files): classify transient PDF ReadAt I/O errors as retryable (bookshelf-qwvg)

zombor added 1 commit 2026-07-08 01:08:24 +00:00

fix(files): classify transient PDF ReadAt I/O errors as retryable (bookshelf-qwvg) ... 051af25334

Review fixes for PR #1010:

[MAJOR] renderPDFPage0FromReader misclassified transient I/O errors (NFS
disconnect, disk error) as permanent ErrNoCover. Introduce trackingReadSeeker
to capture any non-EOF Read error during OpenDocument. After OpenDocument
fails: if a Read error was recorded, return it unwrapped (retryable — the
wfengine adapter maps ErrNoCover→permanent, NOT this path); otherwise the
bytes were readable but pdfium rejected the content → ErrNoCover (permanent,
corrupt/password-protected PDF). Domain-sentinel boundary preserved; no
workflow engine import.

[MINOR] Delete readSeekerAt — dead production code with no remaining callers
after this PR's streaming refactor. Remove the NewReadSeekerAt export shim
and all readSeekerAt tests (including the "Read with buffer larger than
remaining bytes" coverage-gaming test for dead code).

[MINOR] Strengthen bytes-read proof: replace solid-colour 400×600 JPEG
fixtures (compress near-zero, tiny margin) with noisy pixel-varied images
(near-incompressible). Assert bytesRead < fileSize/2 with an explanatory
comment. The security guarantee rests on the WASM memory cap + deadline;
this supporting signal is now quantitatively robust.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

zombor referenced this pull request from a commit 2026-07-08 01:19:21 +00:00

fix(files): classify transient PDF ReadAt I/O errors as retryable (bookshelf-qwvg)

zombor force-pushed bd-bookshelf-qwvg from 051af25334 to 11d6400286 2026-07-08 01:19:21 +00:00 Compare

zombor merged commit 93794f9036 into main 2026-07-08 01:24:31 +00:00

zombor referenced this pull request from a commit 2026-07-08 01:24:34 +00:00

Merge pull request 'Stream PDF cover render via FPDF_LoadCustomDocument (bookshelf-qwvg)' (#1010) from bd-bookshelf-qwvg into main

zombor referenced this pull request 2026-07-08 02:11:58 +00:00

feat(wdow): stream LLM-scan PDF render path, remove 200MB size gate #1015

zombor referenced this pull request 2026-07-08 02:36:34 +00:00

feat(wdow): stream LLM-scan PDF render path, remove 200MB size gate #1015

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

zombor/pergamum!1010

No description provided.