fix(pdf-server): detached-buffer on range re-request + stale e2e assertion#561
Merged
fix(pdf-server): detached-buffer on range re-request + stale e2e assertion#561
Conversation
@modelcontextprotocol/ext-apps
@modelcontextprotocol/server-basic-preact
@modelcontextprotocol/server-basic-react
@modelcontextprotocol/server-basic-solid
@modelcontextprotocol/server-basic-svelte
@modelcontextprotocol/server-basic-vanillajs
@modelcontextprotocol/server-basic-vue
@modelcontextprotocol/server-budget-allocator
@modelcontextprotocol/server-cohort-heatmap
@modelcontextprotocol/server-customer-segmentation
@modelcontextprotocol/server-debug
@modelcontextprotocol/server-map
@modelcontextprotocol/server-pdf
@modelcontextprotocol/server-scenario-modeler
@modelcontextprotocol/server-shadertoy
@modelcontextprotocol/server-sheet-music
@modelcontextprotocol/server-system-monitor
@modelcontextprotocol/server-threejs
@modelcontextprotocol/server-transcript
@modelcontextprotocol/server-video-resource
@modelcontextprotocol/server-wiki-explorer
commit: |
PDF.js transfers the ArrayBuffer to its worker via postMessage, detaching it in the main thread. When the same range is re-requested (common on iOS/WKWebView under memory pressure during scroll/zoom/navigate), the cached Uint8Array now wraps a detached buffer and onDataRange throws 'Buffer is already detached'. Fix: pass result.bytes.slice() so the rangeCache entry stays valid.
…t text The 91880a6 prompt rewrite changed the interact-enabled result text from 'Displaying PDF (viewUUID: ...)' to 'PDF opened. viewUUID: ...'. The e2e test was still asserting the old string.
ochafik
force-pushed
the
ochafik/pdf-detached-buffer-fix
branch
from
76b42b8 to
efed982
Compare
ochafik
changed the title
ochafik
added a commit
that referenced
this pull request
Mar 23, 2026
Changes since 1.3.0: - fix(pdf-server): detached-buffer on range re-request + stale e2e assertion (#561)
ochafik
added a commit
that referenced
this pull request
Mar 23, 2026
Changes since 1.3.0: - fix(pdf-server): detached-buffer on range re-request + stale e2e assertion (#561)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
1. "Buffer is already detached" on iOS/Windows
PDFDataRangeTransport.onDataRange()transfers the ArrayBuffer to PDF.js's worker viapostMessage, detaching it in the main thread. TherangeCachestill holds a reference to that (now-detached)Uint8Array. When PDF.js re-requests the same range — common on iOS/WKWebView under memory pressure during scroll/zoom — we hand back the detached buffer and it throws.Fix: pass
result.bytes.slice()toonDataRangeso the cache entry keeps a valid buffer.2. Stale e2e assertion
The interact-enabled
display_pdfresult text changed fromDisplaying PDF (viewUUID: ...)toPDF opened. viewUUID: ...during the prompt rewrite, butpdf-annotations.spec.ts:110still asserted the old string. This was failing on main post-#506.