The e2e test tests/e2e/pdf-incremental-load.spec.ts › annotation tombstone preservation is currently test.fixme (see #639). It guards the restoredRemovedIds union in mcp-app.ts persistAnnotations() — a deletion on an unvisited page must survive a persistAnnotations() triggered elsewhere after a viewer reload.
Why it can't run today: the load-bearing scenario needs a fresh viewer load that reads the same localStorage key as the prior session. The key is pdf-annot:${toolId}, and:
- inner-iframe
location.reload() → basic-host doesn't re-postMessage the cached tool result, so the viewer never gets data
- a fresh
display_pdf call → new toolId → new storage key → restore misses
Options (any one unblocks the test):
- basic-host replays tool result on iframe
onload (~10 lines in basic-host; benefits any MCP App that reloads its iframe).
- URL-keyed annotation storage —
annotationStorageKey() keys on the PDF URL (or a hash) instead of toolId. Annotations would survive across conversations for the same PDF, which is arguably the right product behaviour anyway.
- Test-only
addInitScript seed — one-shot localStorage.getItem shim returning the seeded diff for the first pdf-annot:* lookup. No prod changes; tests the real restoreAnnotations() → persistAnnotations() path.
The fix is currently covered by the computeDiff/serializeDiff contract tests in examples/pdf-server/src/pdf-annotations.test.ts, but those don't reach the DOM-coupled glue.
The e2e test
tests/e2e/pdf-incremental-load.spec.ts › annotation tombstone preservationis currentlytest.fixme(see #639). It guards therestoredRemovedIdsunion inmcp-app.ts persistAnnotations()— a deletion on an unvisited page must survive apersistAnnotations()triggered elsewhere after a viewer reload.Why it can't run today: the load-bearing scenario needs a fresh viewer load that reads the same
localStoragekey as the prior session. The key ispdf-annot:${toolId}, and:location.reload()→ basic-host doesn't re-postMessage the cached tool result, so the viewer never gets datadisplay_pdfcall → newtoolId→ new storage key → restore missesOptions (any one unblocks the test):
onload(~10 lines in basic-host; benefits any MCP App that reloads its iframe).annotationStorageKey()keys on the PDF URL (or a hash) instead oftoolId. Annotations would survive across conversations for the same PDF, which is arguably the right product behaviour anyway.addInitScriptseed — one-shotlocalStorage.getItemshim returning the seeded diff for the firstpdf-annot:*lookup. No prod changes; tests the realrestoreAnnotations()→persistAnnotations()path.The fix is currently covered by the
computeDiff/serializeDiffcontract tests inexamples/pdf-server/src/pdf-annotations.test.ts, but those don't reach the DOM-coupled glue.