Summary
[heartbeat] default_timeout_secs in ~/.openfang/config.toml appears to be ignored. Regardless of the configured value, the kernel heartbeat marks agents unresponsive using a hardcoded 60s timeout.
Version
- OpenFang v0.6.9 (
openfang 0.6.9)
- Provider:
claude-code (Claude Max OAuth), Linux, systemd --user gateway
Config set
[heartbeat]
default_timeout_secs = 86400
Expected
Idle/long-lived agents should not be flagged unresponsive until inactive_secs >= default_timeout_secs (86400).
Actual
The heartbeat uses timeout_secs=60 no matter what the config says. Example log lines (config is 86400, yet timeout_secs is 60):
WARN openfang_kernel::heartbeat: Agent is unresponsive agent=pv-eli inactive_secs=1200 timeout_secs=60
WARN openfang_kernel::heartbeat: Agent is unresponsive agent=pv-nano inactive_secs=1200 timeout_secs=60
WARN openfang_kernel::heartbeat: Agent is unresponsive agent=pv-finley inactive_secs=1200 timeout_secs=60
(Setting the value to 600 previously showed the same timeout_secs=60 in logs, so the key has no effect.)
Repro
- Set
[heartbeat] default_timeout_secs = 86400 in ~/.openfang/config.toml.
- Restart the gateway.
- Leave any agent idle for >60s.
- Observe
openfang_kernel::heartbeat warns Agent is unresponsive ... timeout_secs=60 — not 86400.
Impact
Idle, schedule/event-driven agents perpetually exceed the 60s window and get marked Crashed, which on our setup drove a continuous auto-recovery cycle. Combined with a continuous orchestrator poll, each recovery fired an LLM (sonnet) subprocess call, producing a steady 24/7 token burn (~570 provider calls/day in our case) entirely from idle-agent churn. Being able to raise the timeout via config would let operators stop this without code changes.
Likely area
crates/openfang-kernel heartbeat path — the per-agent timeout seems to fall back to a hardcoded 60s default rather than reading heartbeat.default_timeout_secs from the loaded config.
Possibly related (closed)
This may be a regression of, or adjacent to, those.
Summary
[heartbeat] default_timeout_secsin~/.openfang/config.tomlappears to be ignored. Regardless of the configured value, the kernel heartbeat marks agents unresponsive using a hardcoded 60s timeout.Version
openfang 0.6.9)claude-code(Claude Max OAuth), Linux, systemd--usergatewayConfig set
Expected
Idle/long-lived agents should not be flagged unresponsive until
inactive_secs >= default_timeout_secs(86400).Actual
The heartbeat uses
timeout_secs=60no matter what the config says. Example log lines (config is 86400, yet timeout_secs is 60):(Setting the value to
600previously showed the sametimeout_secs=60in logs, so the key has no effect.)Repro
[heartbeat] default_timeout_secs = 86400in~/.openfang/config.toml.openfang_kernel::heartbeatwarnsAgent is unresponsive ... timeout_secs=60— not 86400.Impact
Idle, schedule/event-driven agents perpetually exceed the 60s window and get marked
Crashed, which on our setup drove a continuous auto-recovery cycle. Combined with a continuous orchestrator poll, each recovery fired an LLM (sonnet) subprocess call, producing a steady 24/7 token burn (~570 provider calls/day in our case) entirely from idle-agent churn. Being able to raise the timeout via config would let operators stop this without code changes.Likely area
crates/openfang-kernelheartbeat path — the per-agent timeout seems to fall back to a hardcoded 60s default rather than readingheartbeat.default_timeout_secsfrom the loaded config.Possibly related (closed)
touch_agent→ heartbeat false-positivesThis may be a regression of, or adjacent to, those.