You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(redis): bound the three unbudgeted stream writers by bytes
The copilot stream buffer, the Tables event log and the realtime file-doc
streams were each bounded by entry count and nothing else. An entry cap bounds
how many entries a key holds and says nothing about how large each one is, so a
single writer emitting large entries reaches gigabytes well inside its cap —
which is how one file-edit stream filled a shared Redis under a 100,000-entry
cap and evicted the whole keyspace.
Each writer gets the bound its read semantics allow:
- Copilot's replay buffer is read from a cursor and must stay contiguous, so it
now reserves bytes against per-stream and per-user ceilings inside the same
Lua that appends, and the writer soft-stops persistence on refusal rather
than failing the live stream.
- The Tables event log is a live feed whose readers already refetch on a prune,
so it drops oldest-first once past a byte ceiling — the existing `pruned`
path carries it, with the running total kept in meta under the same TTL as
the bytes it counts.
- The file-doc streams are Yjs deltas replayed in full by a task attaching
later, so dropping the oldest would lose edits and a native MAXLEN bound is
unsafe. Compaction, which folds deltas into a snapshot first, is lossless —
it now triggers on appended bytes as well as entry count.
Also folds `lib/execution/redis-budget.server.ts` into the shared module rather
than leaving two definitions of the same prefix and ceilings writing the same
Redis keys. Key layout and every execution limit are unchanged, and pinned by
test.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments