Skip to content

Add stage-by-stage logging to the search text-layer pipeline (#147 diagnostics) - #150

Merged
philips merged 1 commit into
mainfrom
log-search-textlayer-pipeline-issue-147
Jul 31, 2026
Merged

Add stage-by-stage logging to the search text-layer pipeline (#147 diagnostics)#150
philips merged 1 commit into
mainfrom
log-search-textlayer-pipeline-issue-147

Conversation

@philips-clanker

Copy link
Copy Markdown
Collaborator

Summary

Diagnostic-only change for #147 (crash/"boot loop" opening a specific .note file on iOS). Not a fix - we don't have a confirmed root cause yet, and this is intended to get one.

What we know so far: the reporter's note is only 8 pages; the render-completion log (main.ts:1027, after parsing/rasterization/ImageBitmap decode/canvas draw for all pages succeed) is the last thing that ever printed - even with Safari's Web Inspector attached live to the device. That rules out parsing/rasterization/canvas rendering as the cause for this report, and points at whatever runs immediately after: the fire-and-forget pipeline that builds a text-only PDF (assembleTextOnlyPdf/pdf-lib) purely so pdf.js can provide a search/select text layer, plus each visible page's own text-layer build in ensureTextLayer().

The concerning part: ensureTextLayer() already wraps its work in try/catch and logs Failed to build text layer for page N: ... on any ordinary thrown exception - and that log never appeared either, with the inspector attached. Whatever's happening is severe enough to leave no catchable JS error and no further console output at all - consistent with a hard native/WASM-level crash or an unresponsive-script watchdog kill, not a normal bug we could just try/catch our way out of blind.

Changes

Adds console.debug checkpoints stage-by-stage:

  • assembleTextOnlyPdf: per-page, plus before saving
  • The pdfDocPromise IIFE in onLoadFile(): before/after building the PDF, loading pdf.js, and parsing it
  • ensureTextLayer(): before awaiting the PDF and before/after building each page's own text layer

Whichever line prints last next time narrows this from "somewhere in a ~6-stage pipeline with zero visibility" down to one specific stage, or one specific page's recognition data - actionable next-step info instead of another log line identical to what we already have.

Test plan

  • npx tsc --noEmit - clean
  • npx eslint src/main.ts - 0 errors
  • npx vitest run - 95 passed
  • npm run build - clean
  • Reporter to reproduce with this build and share whichever console.debug line prints last

Investigating #147 (crash/"boot loop" opening a .note file on iOS):
the reporter's only log line was the page-render completion message
right before this pipeline starts, even with Safari's Web Inspector
attached live - meaning whatever happens next crashes hard enough that
no catchable JS error, and no further console output at all, ever
appears. ensureTextLayer()'s existing try/catch only logs an ordinary
thrown exception, and only runs once a page's IntersectionObserver
callback actually fires.

Adds a console.debug checkpoint before/after each stage: building the
text-only PDF (assembleTextOnlyPdf, now also per-page inside that
loop), loading pdf.js, parsing the PDF, and - separately - each page's
own text-layer build in ensureTextLayer(). Whichever line prints last
next time narrows the crash to one specific stage (or one specific
page's recognition data) instead of a silent gap between two log
lines spanning the whole pipeline.
@philips
philips merged commit 1bfd72f into main Jul 31, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants