mirror of
https://github.com/block/buzz.git
synced 2026-10-30 22:11:36 +00:00
e5f73cd27c
PR #6115 seats a 660 s client budget for mesh agents in the desktop (`managed_agents/relay_mesh.rs`) because MeshLLM's own backend budget is 600 s and a cold prefill of a large agent prompt can legitimately take ~500 s. On this branch that seed reached nothing: buzz-agent no longer has a request loop, and `project_goose_env` had no projection for the variable, so goose's own default applied instead. goose's default is 600 s (`DEFAULT_PROVIDER_TIMEOUT_SECS`) — just *under* the mesh server's, which is the same wrong-side-of-the-server ordering #6115 diagnosed. So the bug #6115 fixes would have come back on merge, silently and only on shared compute. goose reads the timeout per provider rather than globally, so this projects onto the variable belonging to the configured provider. `relay-mesh` maps to goose's `openai` provider and so reads `OPENAI_TIMEOUT` (`goose/src/providers/openai_def.rs:118`). Providers goose gives no timeout knob — databricks — return `None` rather than getting a variable goose never reads. Two tests. The mesh one asserts the invariant (`> 600`) rather than the literal, and I verified it fails with the projection removed and the test kept, reconstructing that baseline from the file rather than `git stash`. README corrected: it claimed this knob was "no longer read", and its limits table still listed the pre-goose 240 s default. Co-authored-by: Michael Neale <michael.neale@gmail.com> Signed-off-by: Michael Neale <michael.neale@gmail.com>