[codex] Fix Kanban retry runtime clock#19828
Conversation
|
Related to #19473 — same retry-runtime-clock root cause (started_at preserved across claims), different fix approach: this PR resets task-level started_at on claim instead of reading from task_runs. |
|
Related to #19473 — same retry-runtime-clock root cause (started_at preserved across claims), different fix approach. |
|
Closed in favor of competing PR #19473 which solved the same retry-timeout-loop bug non-destructively (JOIN on |
|
wow big teknium commenting in my pull request... thank you for everything you and the team have put out in the world! love Hermes so much :) |
Summary
started_attimestamp on every Kanban claim.Root Cause
claim_taskpreservedtasks.started_atwithCOALESCE(started_at, ?), while max-runtime enforcement reads the task-levelstarted_atvalue. When a blocked or timed-out task was retried, the retry could inherit an old runtime clock and immediately time out again.Impact
Retries now receive a fresh task runtime window when they are claimed again. Attempt history is still preserved in
task_runs, but the active task record reflects the current attempt's runtime clock.Validation
/home/clockwork/.hermes/hermes-agent/venv/bin/python -m pytest tests/hermes_cli/test_kanban_core_functionality.py -k 'claim_resets_task_started_at_after_unblock or timeout_retry_uses_fresh_task_started_at or enforce_max_runtime_integrates_with_dispatch'/home/clockwork/.hermes/hermes-agent/venv/bin/python -m pytest tests/hermes_cli/test_kanban_core_functionality.py