#811 Approval-timeout recovery is flaky under repetition/load (#810 residual, #agentic)

closed medium agentic Created 2026-07-05 03:25 · Updated 2026-07-05 16:37

Description

Edit
HONEST CORRECTION to my #810 report. #810 FIXED the permanent-hang class (0 infinity, 0 corrupted - verified). But the PROMPT recovery of a timed-out approval is NOT reliable: on repeated runs hitl_timeout_reject passes only ~2/5 within 200s; the rest stay sleeping past 200s (bare agent_* keys, so a delivery race, not #752). When the sweeper's emit_event delivers, the run completes in ~20s; when emit misses, the durable timeout-wake (wait-row timeout / reconcile) is supposed to recover it at ~28-60s but often does not within 200s under load. Root likely still in the emit-vs-await_event delivery race (event-row payload/tenant, checkpoint under the wait step) that set_run_sleeping's wait re-registration only partially closed. My earlier '18/18 + 5/5' was an optimistic sample. Impact: the max_usd/timeout HITL feature works but its recovery latency is unreliable - a golden-test-flaky. Needs a focused delivery-race fix (or a deterministic timeout->reject that does not depend on emit delivery).

Comments

Loading comments...

Context

Loading context...

Audit History

View All
Loading audit history...