Repository navigation
fix(viewer): drain WebSocket messages in frame-budgeted slices, not all at once - #32
Merged
ericgozzi merged 3 commits intoOct 13, 2026
Conversation
…ll at once A caller loading a large scene (one element per message, no send-side batching) can burst thousands of WebSocket messages at once. Dispatching each one synchronously inside onmessage - real work per message: protobuf decode plus a Three.js scene mutation - pinned the main thread for the whole burst, which made the tab look/become unresponsive and, past the browser's own patience, drop the WebSocket connection entirely. ViewerConnection now queues incoming messages and drains them, in order, in up to FRAME_BUDGET_MS (8ms) slices per requestAnimationFrame, picking up where it left off on the next frame. The queue uses a head index instead of Array.shift() per message to avoid an O(n^2) drain, and a throw from one message's dispatch is caught so it can't strand every message queued after it. dispose() cancels a pending drain and drops whatever is still queued. Adds tests/viewer_connection.test.ts, covering the multi-frame drain itself and dispose() cancelling a pending one. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This was referenced Sep 23, 2026
ericgozzi
added this pull request to stack #34
September 23, 2026 06:27
gonzalocasas
approved these changes
Oct 11, 2026
gonzalocasas
left a comment
gonzalocasas
left a comment
Member
There was a problem hiding this comment.
LGTM, it's an interesting solution
Comment on lines
+114
to
+138
| while (this.inboxHead < this.inbox.length && performance.now() < deadline) { | ||
| const message = this.inbox[this.inboxHead]!; | ||
| // Advance past this message BEFORE dispatching it, and catch a throw from | ||
| // dispatch() itself - one malformed/unsupported message must never silently | ||
| // strand every message queued after it (which would otherwise happen here: an | ||
| // uncaught throw exits this loop without rescheduling, so the drain simply never | ||
| // resumes). options.dispatch already reports most failures through its own | ||
| // onError callback instead of throwing, but this is the difference between one | ||
| // skipped message and the rest of a large model - including a final "stop | ||
| // loading" message - never arriving at all. | ||
| this.inboxHead += 1; | ||
| try { | ||
| this.options.dispatch(message); | ||
| } catch (error) { | ||
| this.options.onError( | ||
| error instanceof Error ? error : new Error(String(error)), | ||
| ); | ||
| } | ||
| } | ||
| if (this.inboxHead >= this.inbox.length) { | ||
| this.inbox.length = 0; | ||
| this.inboxHead = 0; | ||
| } else { | ||
| this.scheduleDrain(); | ||
| } |
Member
There was a problem hiding this comment.
If you want to be suuuuper picky, you could wrap the scheduling of next draining into a try..finally, something like:
try {
// here the while() and all that stuff
} finally {
if (this.inboxHead >= this.inbox.length) {
this.inbox.length = 0;
this.inboxHead = 0;
} else {
this.scheduleDrain();
}
}…hrows Wrap the drain loop in try/finally so a throw escaping it (e.g. from onError while reporting a failed dispatch) can no longer leave messages queued with no drain pending. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Clears two high-severity advisories that fail audit:prod: GHSA-g2v6-rqmx-r4w6 (@vue/server-renderer) and GHSA-68fv-2mgg-jv7q (source-map-js). Lockfile-only, generated with npm 10 to match CI. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
Summary
onmessage(protobuf decode plus a Three.js scene change), which blocked the main thread for the whole burst. The tab froze and could eventually drop the WebSocket connection.ViewerConnectionnow queues incoming messages and drains them in order, in slices of up toFRAME_BUDGET_MS(8 ms) perrequestAnimationFrame. The queue tracks a head index instead of callingArray.shift(), so draining isn't O(n²). An error while handling one message is caught so it can't block the messages after it.dispose()cancels any pending drain and drops the queue.Stacked on #31; merge that first. Next in stack: #33.
Test plan
tests/viewer_connection.test.ts(a drain spread over several frames;dispose()cancelling a pending drain)🤖 Generated with Claude Code