agentd: raise Finite Chat bridge readiness deadline 30s → 180s - #571
Merged
Conversation
Bridge cold start reprocesses retained room history before serving, so time-to-ready scales with data size, not spawn speed. On 2026-08-18 an agent with a ~15k-message room needed ~55s to become ready on lat3 and boot-looped forever: agentd killed the bridge at the 30s deadline on every start, and operator restarts reproduced the loop deterministically. 180s gives large rooms headroom on slow hosts; a genuinely dead bridge still fails and is retried within minutes. Root-causing the startup cost itself is tracked separately.
futurepaul
force-pushed
the
agentd-bridge-ready-timeout
branch
from
August 18, 2026 21:27
0be373c to
51fd99a
Compare
This was referenced Aug 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Raises the hard-coded agentd → Finite Chat bridge readiness deadline from 30s to 180s (
finite-agentd/src/daemon.rs).Why
The bridge's cold start reprocesses retained room history before it serves, so time-to-ready scales with data size and host I/O, not process spawn speed. On 2026-08-18 a production agent with a ~15k-message room needed ~55s to become ready on lat3 (measured twice, same image + store copy, fresh kata VM). Against the 30s deadline that agent boot-looped deterministically for ~3h: agentd killed the bridge mid-startup on every attempt, Core-recorded restarts reported success, and the agent never came back.
A warm (already-at-head) store still took ~54s, so this is fixed per-boot cost proportional to history — every hosted agent drifts toward the cliff as its rooms grow. Fleet census today: 1/29 unhealthy on lat3 (this agent), 0/22 on lat1.
Why 180s and not fixing the startup cost here
The deadline raise un-breaks large rooms now; the startup-cost root cause is a separate follow-up (postmortem in the org Brain). A genuinely dead bridge still fails within 3 minutes and is retried.
Test
cargo test -p finite-agentd(31 passed),cargo clippy -p finite-agentd -- -D warningsclean.