* fix(buzz): messages sent during Gateway downtime are dropped after restart
Every new Gateway process subscribed to Buzz rooms starting at its own
start time, because the lookback flag that enables backlog paging is
process-local. That cutoff is applied as the NIP-01 since filter, so any
room message a human sent while the process was down was never returned
by the relay and never reached the agent or the transcript.
The account gateway now persists a per-account recovery watermark in the
plugin state store. First-ever setup still starts from the current time;
later process starts resume from the saved watermark, clamped to the
existing 24 hour retention floor. The watermark advances only after
inbound handling completes and is stored at the admitted message
created_at, so the inclusive since boundary re-offers the last admitted
message to the existing persistent event-id dedupe guard.
* fix(buzz): keep the cold-start recovery cursor behind unfinished work
Codex review found two ways the recovery watermark could still drop room
messages. Backlog replay dispatches up to eight handlers concurrently, so
a newer message finishing before an older one committed the newer
timestamp; a crash then left the older message with no dedupe record and
a cursor already past it. The stored timestamp was also the sender
controlled created_at, so a future dated room event pushed the cursor
past locally observed time and excluded real downtime messages on the
next start.
The account gateway now tracks a recovery frontier per session. A
checkpoint is the highest completed message time bounded by the oldest
still running message, the oldest failed message, and the receipt time
observed when the message was admitted. Checkpointing stays closed until
the bus reports the room backlog fully drained, so a session that is
still paging history cannot commit past events it has not seen yet.
catchUpHistory now reports drained or incomplete for that signal.
* fix(buzz): scope cold-start recovery per room and fence it at enqueue
Admit replay work into the recovery frontier when it enters the dispatch queue instead of when a worker starts it, so a crash cannot persist a cutoff past an event that is still queued.
Key recovery cursors by room instead of by account, so a room configured after the first start resolves to the current time and gets no backfill, while existing rooms resume from their own cursor.
Record an account-level start marker so the first start under a watermark-aware build recovers the existing retention window instead of repeating the reported loss on the first restart after an upgrade.
* fix(buzz): keep cold-start recovery to accounts that already ran
An account with no persisted cursor is a fresh install as often as it is a
pre-watermark upgrade, and stored state cannot tell them apart, so the first
start no longer replays the retention window. It records the current time as
each room cursor and recovers only from the second start onward.
Dropping the account start marker also removes the interrupted-bootstrap
window where a marker written before the room cursors made the next start
treat cursor-less rooms as initialized.
Recovery state capacity is now derived from the supported room limit instead
of a smaller fixed number, and any non-complete history paging outcome, not
just timestamp-over-limit, holds the recovery frontier undrained.
* fix(buzz): bound the recovery cursor store to each account
ClawSweeper found that the recovery watermark opened one fixed plugin-state
namespace for every account while sizing it at the per-account supported room
count. Plugin-state capacity is enforced per plugin and namespace, so once one
account registered its full room allowance, a second account's register call
threw and its rooms stayed at the current-time cutoff, which is the same
dropped-message outcome this PR set out to fix.
The store is now opened against a namespace derived from the account identity,
so each account carries its own supported room capacity. The account moves out
of the entry key into the namespace, which leaves one account-scoped store path
rather than a fallback, and makes cross-account cursor mixing unrepresentable.
* fix(buzz): simplify durable restart recovery
Co-authored-by: yetval <yetvald@gmail.com>
* test(buzz): use real relay response in recovery fixture
Co-authored-by: yetval <yetvald@gmail.com>
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Reject malformed relay metadata and cancel oversized response streams at the existing 16 MiB provider boundary.
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(channels): validate headless channel setup
* docs(channels): document headless provisioning
* fix(channels): repair setup metadata typing
* chore(channels): regenerate official channel catalog for env metadata
* fix(slack): keep mode-conditional env contract plugin-owned
Static --use-env declaration keeps only the unconditional SLACK_BOT_TOKEN;
socket-vs-HTTP conditional requirements (app token, signing secret) stay in
Slack's own setup validation so HTTP mode no longer demands an irrelevant
SLACK_APP_TOKEN.
* chore(sdk): regenerate api baselines and catalog after rebase
* fix(slack): align manifest env declaration with runtime contract
* chore(sdk): regenerate api baselines after rebase
* chore(sdk): regenerate api baselines after rebase
* chore(sdk): regenerate api baselines after rebase
* fix(buzz): page reconnect history instead of dropping older messages
On reconnect the Buzz gateway asked the relay for a single capped page of
room history and treated EOSE as a complete recovery. Any backlog larger
than the per-room replay limit was never requested again, so those messages
never reached handleBuzzInbound, the agent, or the session transcript, and
nothing reported the loss.
The room subscription now records how much history its first page returned
and, when that page filled the limit, pages older history through the relay
until it is exhausted. Each page is dispatched through the existing bounded
replay queue and the next page waits for queue capacity, so recovery stays
memory bounded. A room whose backlog cannot be paged past a single
timestamp is now reported instead of dropped silently.
Membership tracking moves to room-membership-tracker.ts because buzz-bus.ts
was already at the 700 line ceiling.
* fix(buzz): hold dispatch capacity while a history page is in flight
Catch-up asked the replay queue whether capacity existed and then issued the
relay query, but nothing held those slots. Live room events arriving while
the query was in flight could consume them, so admitting the page afterwards
could report overflow, which closes the dispatch queue and drops every
queued message before forcing a reconnect. A busy room with slow inbound
handlers could repeat that instead of finishing recovery.
Capacity is now reserved rather than sampled. reserveCapacity resolves with a
reservation that owns its slots until released, page events are admitted
through that reservation, and the reservation is released once the page is
enqueued. Live enqueues keep the full pending limit and are never rejected
earlier because a reservation is outstanding. An overflow reported through a
reservation means the relay exceeded the page it was asked for, so it is
reported as a history error instead of tearing down the session.
* fix(buzz): bound reconnect history pages
* fix(buzz): preserve replay reservations
* test(buzz): cover catch-up settlement paths
* fix(buzz): drain saturated history ranges
---------
Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
Restore standalone Buzz npm and ClawHub packaging by using the shipped QA runner SDK surface and generated dependency lock workflow.
Prepared head SHA: 58d0a52c61
Co-authored-by: Shakker <165377636+shakkernerd@users.noreply.github.com>
Reviewed-by: @shakkernerd
Yuval Dinodia