fix(discord): bound gateway websocket payloads by sunlit-deng · Pull Request #99998 · openclaw/openclaw

sunlit-deng · 2026-07-04T14:57:13Z

What Problem This Solves

Fixes an issue where Discord gateway connections could accept oversized inbound WebSocket frames before gateway payload validation ran.

Why This Change Was Made

Gateway WebSocket clients now set a 16 MiB maxPayload cap. The same cap is applied to the monitor/proxy wrapper path so normal Discord startup uses the bounded transport too, while still allowing large gateway events such as member chunks that can exceed 1 MiB.

User Impact

Discord gateway users get normal gateway behavior for large guild traffic, with oversized frames still rejected by the WebSocket client before they can grow toward the upstream 100 MiB default.

Evidence

Red before fix: node scripts/run-vitest.mjs extensions/discord/src/internal/gateway-websocket-options.test.ts extensions/discord/src/monitor/provider.proxy.test.ts --reporter=verbose failed because gateway socket constructors did not include maxPayload.
node scripts/run-vitest.mjs extensions/discord/src/internal/gateway.test.ts extensions/discord/src/monitor/gateway-plugin.test.ts extensions/discord/src/monitor/provider.proxy.test.ts extensions/discord/src/internal/gateway-websocket-options.test.ts --reporter=verbose: passed 4 files, 66 tests.
node_modules/.bin/oxfmt --check extensions/discord/src/internal/gateway.ts extensions/discord/src/internal/gateway-websocket-options.test.ts extensions/discord/src/monitor/gateway-plugin.ts extensions/discord/src/monitor/gateway-plugin.test.ts extensions/discord/src/monitor/provider.proxy.test.ts && git diff --check: passed.
Loopback proof with real GatewayPlugin and ws server:

configuredMaxPayloadBytes=16777216
largeMemberChunkBytes=1947001
largeMemberChunkOverOneMiB=true
largeMemberChunkUnderCap=true
largeMemberChunkDispatches=1
oversizedFrameBytes=16777280
clientRejectedOversized=true
serverCloseCode=1009

AI-assisted: built with Codex

clawsweeper · 2026-07-04T14:58:21Z

Codex review: needs maintainer review before merge. Reviewed July 4, 2026, 11:33 AM ET / 15:33 UTC.

Summary
The branch adds a shared 16 MiB Discord gateway WebSocket maxPayload and updates internal/monitor gateway tests to assert the cap in direct and proxy socket paths.

PR surface: Source +2, Tests +54. Total +56 across 5 files.

Reproducibility: yes. with source-level reproduction rather than a local run: current main constructs both Discord gateway socket paths without maxPayload, and the ws dependency defaults the client receive limit to 100 MiB. The PR body adds loopback output showing under-cap dispatch and over-cap rejection after the fix.

Review metrics: 1 noteworthy metric.

Gateway receive limit: 2 constructors capped at 16 MiB, down from the ws 100 MiB default. This is a fail-closed runtime default change for Discord gateway receives, so maintainers should explicitly notice the compatibility tradeoff before merge.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P2] Maintainers should explicitly accept the 16 MiB Discord gateway receive cap or request live large-guild proof before merge.

Risk before merge

[P1] Merging this intentionally changes existing Discord gateway behavior from the ws 100 MiB receive default to a fixed 16 MiB cap, so any valid Discord gateway event above that size would fail closed before OpenClaw can process it.
[P1] The PR body proves a roughly 1.95 MiB member-chunk-style event and an over-cap loopback rejection, but it does not prove a live large-guild Discord session cannot produce a legitimate event above 16 MiB.

Maintainer options:

Accept the 16 MiB receive cap (recommended)
Maintainers can accept the lower bounded default after CI, owning the rare-event risk that a valid Discord gateway payload above 16 MiB would reconnect/fail closed.
Request live large-guild proof
Ask for live Discord or artifact-backed large-guild validation if the 16 MiB threshold needs stronger compatibility evidence before merge.
Retune the cap before merge
Raise the fixed cap in the Discord plugin if maintainers want a wider safety margin while still avoiding the upstream 100 MiB default.

Next step before merge

[P2] No automation repair is needed; the remaining action is maintainer acceptance of the 16 MiB Discord gateway receive cap and normal merge validation.

Security
Cleared: No supply-chain, secret-handling, permission, or security-boundary regression was found; the diff narrows a memory/DoS exposure while leaving a compatibility/availability policy risk for maintainers.

Review details

Best possible solution:

Keep the bounded Discord gateway receive hardening if maintainers accept the 16 MiB cap; otherwise adjust the cap or require live large-guild proof before merge.

Do we have a high-confidence way to reproduce the issue?

Yes, with source-level reproduction rather than a local run: current main constructs both Discord gateway socket paths without maxPayload, and the ws dependency defaults the client receive limit to 100 MiB. The PR body adds loopback output showing under-cap dispatch and over-cap rejection after the fix.

Is this the best way to solve the issue?

Mostly yes: the Discord plugin socket construction path is the right owner boundary, and the second commit resolves the earlier unsafe 1 MiB cap by raising it to 16 MiB. The remaining question is whether maintainers accept that exact fail-closed threshold for upgrades.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against ba7b5db74c91.

Label changes

Label justifications:

P2: This is focused Discord gateway hardening with limited surface area and no evidence of an active production outage.
merge-risk: 🚨 compatibility: Existing Discord users upgrade from the ws 100 MiB receive default to a fixed 16 MiB cap that could reject rare valid large gateway events.
merge-risk: 🚨 availability: An over-cap gateway frame closes the WebSocket before OpenClaw can process it, causing reconnect behavior or loss of that event.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes after-fix loopback live output from a real GatewayPlugin and ws server showing an under-cap large event dispatching and an over-cap frame rejected with close code 1009.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix loopback live output from a real GatewayPlugin and ws server showing an under-cap large event dispatching and an over-cap frame rejected with close code 1009.

Evidence reviewed

PR surface:

Source +2, Tests +54. Total +56 across 5 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	2	4	2	+2
Tests	3	55	1	+54
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	5	59	3	+56

What I checked:

Repository policy read: Root and scoped extension policy were read; the review applied the requirements to inspect the Discord plugin boundary, caller/callee paths, dependency contract, tests, and compatibility-sensitive runtime default changes. (AGENTS.md:11, ba7b5db74c91)
Current main internal gateway behavior: Current main constructs the base Discord gateway WebSocket with new ws.WebSocket(url) and no maxPayload, so the PR changes the dependency default for inbound frame size. (extensions/discord/src/internal/gateway.ts:174, ba7b5db74c91)
Current main monitor wrapper behavior: Normal Discord startup uses the monitor wrapper path, which currently passes handshake timeout and optional agent but no maxPayload. (extensions/discord/src/monitor/gateway-plugin.ts:270, ba7b5db74c91)
PR internal gateway cap: The PR head defines DISCORD_GATEWAY_WS_MAX_PAYLOAD_BYTES = 16 * 1024 * 1024 and passes it to the base gateway WebSocket constructor. (extensions/discord/src/internal/gateway.ts:51, 5d38f059757d)
PR monitor wrapper cap: The PR head reuses the same 16 MiB constant in the monitor/proxy WebSocket override, so both Discord gateway socket construction paths share the bound. (extensions/discord/src/monitor/gateway-plugin.ts:270, 5d38f059757d)
Focused test coverage: The new internal gateway test asserts the 16 MiB maxPayload, and monitor/proxy tests assert the same option in direct and proxy socket paths. (extensions/discord/src/internal/gateway-websocket-options.test.ts:30, 5d38f059757d)

Likely related people:

steipete: Recent history shows direct work on the Discord gateway WebSocket transport and adjacent gateway lifecycle behavior, including the move to the ws transport that this PR adjusts. (role: recent area contributor; confidence: high; commits: 074e6d5047e7, d35cc6ef86dd; files: extensions/discord/src/monitor/gateway-plugin.ts, extensions/discord/src/internal/gateway.ts)
vincentkoc: Recent Discord proxy and bundled-channel hardening touched the monitor gateway/proxy path and tests that this PR updates. (role: recent adjacent hardening contributor; confidence: medium; commits: 50e1eb56d761, e085fa1a3ffd; files: extensions/discord/src/monitor/gateway-plugin.ts, extensions/discord/src/monitor/provider.proxy.test.ts, extensions/discord/src/internal/gateway.ts)
scoootscooob: The Discord channel implementation was moved under extensions/, establishing the current bundled plugin boundary for this code path. (role: extension migration contributor; confidence: medium; commits: 5682ec37fada; files: extensions/discord/src/internal/gateway.ts, extensions/discord/src/monitor/gateway-plugin.ts)
SARAMALI15792: Recent work fixed stale heartbeat timers in the same Discord gateway socket lifecycle area, making this person relevant for adjacent behavior review. (role: recent gateway lifecycle contributor; confidence: low; commits: 7995e408ce99; files: extensions/discord/src/monitor/gateway-plugin.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (3 earlier review cycles)

reviewed 2026-07-04T15:02:21.928Z sha 25bd7ac :: found issues before merge. :: [P1] Prove the 1 MiB gateway receive cap is safe
reviewed 2026-07-04T15:09:30.831Z sha 25bd7ac :: found issues before merge. :: [P1] Prove the 1 MiB gateway receive cap is safe
reviewed 2026-07-04T15:27:55.866Z sha 5d38f05 :: needs maintainer review before merge. :: none

steipete · 2026-07-06T16:09:43Z

Merged via squash.

Prepared head SHA: 18a8b917a827cc2615e7cfff2349c9559974ce2a
Landed commit: de1bac6bc0636199df0d40e2bcc812efd9f01e5b

* fix(discord): bound gateway websocket payloads * fix(discord): raise gateway payload cap for large events * refactor(discord): centralize gateway websocket policy --------- Co-authored-by: Peter Steinberger <[email protected]>

openclaw-barnacle Bot added channel: discord Channel integration: discord size: S triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. labels Jul 4, 2026

openclaw-barnacle Bot removed the triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. label Jul 4, 2026

Pick-cat mentioned this pull request Jul 6, 2026

fix(qqbot): bound gateway websocket payloads #100588

Closed

steipete self-assigned this Jul 6, 2026

steipete force-pushed the sunlit/fix/discord-gateway-ws-max-payload branch from 5d38f05 to d18d252 Compare July 6, 2026 16:07

sunlit-deng and others added 3 commits July 6, 2026 17:09

fix(discord): bound gateway websocket payloads

b4aad9c

fix(discord): raise gateway payload cap for large events

2ce8f0c

refactor(discord): centralize gateway websocket policy

18a8b91

steipete force-pushed the sunlit/fix/discord-gateway-ws-max-payload branch from d18d252 to 18a8b91 Compare July 6, 2026 16:09

steipete merged commit de1bac6 into openclaw:main Jul 6, 2026
35 checks passed

steipete mentioned this pull request Jul 6, 2026

test(discord): align proxy WebSocket override type #101003

Closed

github-actions Bot mentioned this pull request Jul 6, 2026

📡 Upstream Digest — 2026-07-06 16:47 UTC curtismercier/openclaw-mods#1223

Open

clawsweeper Bot mentioned this pull request Jul 6, 2026

fix(cli): keep UTF-8 log tails valid #101029

Merged

dwc1997 mentioned this pull request Jul 7, 2026

fix(mattermost): bound gateway websocket payloads at 16 MiB #101404

Closed

clawsweeper Bot mentioned this pull request Jul 7, 2026

fix(discord): disable ws 8.21.0 receiver part limits for gateway sockets #89041

Closed

clawsweeper Bot mentioned this pull request Jul 8, 2026

fix(qqbot): bound gateway websocket payloads #99075

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(discord): bound gateway websocket payloads#99998

fix(discord): bound gateway websocket payloads#99998
steipete merged 3 commits into
openclaw:mainfrom
sunlit-deng:sunlit/fix/discord-gateway-ws-max-payload

sunlit-deng commented Jul 4, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jul 4, 2026 •

edited

Loading

Uh oh!

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

sunlit-deng commented Jul 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Uh oh!

clawsweeper Bot commented Jul 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

sunlit-deng commented Jul 4, 2026 •

edited

Loading

clawsweeper Bot commented Jul 4, 2026 •

edited

Loading