mirror of https://github.com/block/buzz.git synced 2026-08-18 06:50:31 +02:00

Files

T

npub1qyvc0c5kl4gqv2fd97fsk46tu378sqgy35vc83rvgfwne90sel7s0ed67dandTyler Longwell d390b01039 fix(agents): spawn create/start harness lazy — close the startup message-loss window

start_managed_agent_process was the last spawn_agent_child call site
passing lazy=false. Eager init makes buzz-acp serially initialize the
full worker pool BEFORE connecting to the relay (lib.rs:1317-1346), so
creating or starting a slow-starting harness (e.g. OpenClaw at 4-10s
per worker) took minutes — and any mention sent during that window
predated the startup watermark and could be missed permanently.

Lazy ordering (already used by manual start, restart, reconcile, and
restore per the F1 note in restore.rs) connects and subscribes first,
captures the watermark immediately, queues accepted work, and
initializes the pool in the cancellable wake task on first flushable
work (lib.rs:1714-1740, :2536-2563). Wake failures retry with capped
backoff; shutdown mid-wake drains and reaps partial pools
(lib.rs:2581-2602).

Regression: a source-contract test pins that no spawn_agent_child call
site passes a literal lazy=false (the function spawns a real OS process,
so the contract is pinned at source level, mirroring the reconnect
backoff source-parsing test pattern). Verified red under the exact
mutation (flipping the new site back to false) and green restored.

Demand-driven pool growth (seed 1, grow on contention) is the agreed
follow-up; this is the correctness half.

Team review in buzz-generic-acp-harnesses: Wren and Max both traced the
lifecycle independently and converged on shipping this alone — bundled
concurrent pool init was rejected (spawn_and_init lacks timeout/shutdown
plumbing; fleet-level thundering herd when restore starts many pairs
concurrently).

Co-authored-by: Tyler Longwell <tlongwell@block.xyz>
Signed-off-by: Tyler Longwell <tlongwell@block.xyz>

2026-07-26 17:32:14 -04:00