fix(collab): HTTP-layer resource caps — proxy body limit + SSE connection caps#41
Merged
Merged
Conversation
…tion caps
Two unbounded HTTP resources bounded on the single-replica task.
S3 — preview proxy request-body limit
handlePreviewHttp forwarded request bodies of any size to the in-
container dev server. A multi-GB upload (buggy SPA, or hostile POST)
would buffer through opencode's heap before the upstream's own 413,
swinging the whole task into memory pressure. Reject declared
Content-Length > 50 MB at the proxy edge with a 413 before opening
the upstream connection. 50 MB is generous — real frontend uploads
go straight to S3, not through the dev server.
S4 — SSE connection caps
Each iframe / participant holds a long-lived SSE stream with a 20-s
heartbeat timer. Two new bounds:
- Per-session concurrency cap (8). Realistic max is 2-3 users ×
2-3 tabs; the 9th connection gets a 429 with a "close a tab"
hint. Caps the fd + per-stream-closure footprint a reconnect
storm or many-tabs client could pile on.
- Idle recycle (2 h). A stream that has delivered zero REAL events
(keepalives don't count) for 2 h is closed server-side. The SPA
auto-reconnects and re-syncs via the connect-time snapshot, so an
active session is never interrupted — only quiet/abandoned
background tabs get recycled, capping max connection age.
Refactor: cancel() and the idle-recycle path now share one guarded
teardown() (clear heartbeat, unregister, set offline, broadcast
typing_stop + participant_left) so neither double-runs.
Co-Authored-By: Claude Opus 4.8 (1M context) <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.
Stability hardening pass (PR 2 of 5). Bounds two unbounded HTTP resources on the single-replica task.
S3 — preview proxy request-body limit
handlePreviewHttpforwarded request bodies of any size to the in-container dev server. A multi-GB upload (buggy SPA, or hostile POST) would buffer through opencode's heap before the upstream's own 413, swinging the whole task into memory pressure.Now: reject declared
Content-Length > 50 MBat the proxy edge with a 413 before opening the upstream connection. 50 MB is generous — real frontend uploads go straight to S3, not through the dev server.S4 — SSE connection caps
Each iframe / participant holds a long-lived SSE stream + 20-s heartbeat timer. Two new bounds:
Refactor:
cancel()and the idle-recycle path now share one guardedteardown()(clear heartbeat, unregister, set offline, broadcast typing_stop + participant_left) so neither double-runs.Files
preview-router.ts—MAX_PREVIEW_BODY_BYTES+ 413 guard inhandlePreviewHttprouter.ts—MAX_SSE_PER_SESSIONcap +SSE_IDLE_DISCONNECT_MSrecycle + sharedteardown()Test plan
curl -X POSTthe preview proxy with aContent-Length: 60000000header → 413 before the request reaches the dev serverSSE idle recycle; the still-open tab silently reconnects (no visible UX change)🤖 Generated with Claude Code