2b0717fe21
Addresses planner audit #5 — a connected client could feed unlimited waypoints / no-go / notes into the Yjs doc, growing the in-memory map and the persisted \`sessions.yjs_state\` blob until OOM or DB blowout. Two guards: 1. **Per-frame**: \`MAX_MESSAGE_BYTES = 256 KB\`. Anything bigger arrives from a buggy or hostile client — a single waypoint add is hundreds of bytes. Oversized frame → \`ws.close(1008)\` and drop the message. 2. **Per-doc**: \`MAX_DOC_BYTES = 5 MB\`. After a sync-message apply succeeds, recompute \`Y.encodeStateAsUpdate(doc).byteLength\`. If it crossed the cap, mark the session \"quarantined\": close every connected client (\`1008 policy violation\`), and short-circuit subsequent handleMessage calls so no further bytes can be applied and the debounced save can't write an oversized blob to Postgres. The 5 MB limit is generous — a typical multi-day route's serialized state is well under 100 KB. The cap exists to make abuse expensive, not to constrain real use. Exports \`MAX_MESSAGE_BYTES\`, \`MAX_DOC_BYTES\`, and \`docByteSize\` for testing. Tests cover: - constants are positive and ordered - docByteSize is 0 for unknown sessions - a realistic 500-waypoint route stays well under the cap - ~6MB of garbage in a Y.Text trips the cap (smoke test for the guard) Full repo: pnpm typecheck / lint / test all green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| journal | ||
| mobile | ||
| planner | ||