From 8a1a42d0985631e267361921aac6020e9ccb0323 Mon Sep 17 00:00:00 2001 From: Teknium <127238744+teknium1@users.noreply.github.com> Date: Tue, 5 May 2026 15:16:32 -0700 Subject: [PATCH] test(kanban): backdate task_runs.started_at alongside tasks.started_at After #19473 landed (enforce_max_runtime reads from task_runs.started_at rather than tasks.started_at), a regression test added earlier still only backdated the tasks column. Backdate both so the test is robust regardless of which column the enforcer reads from. --- tests/hermes_cli/test_kanban_core_functionality.py | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/tests/hermes_cli/test_kanban_core_functionality.py b/tests/hermes_cli/test_kanban_core_functionality.py index 1bf0ad4c7c..95dfdae82d 100644 --- a/tests/hermes_cli/test_kanban_core_functionality.py +++ b/tests/hermes_cli/test_kanban_core_functionality.py @@ -3237,10 +3237,21 @@ def test_enforce_max_runtime_increments_consecutive_failures(kanban_home, monkey ) kb.claim_task(conn, tid) kb._set_worker_pid(conn, tid, os.getpid()) + # Since PR #19473 (salvaged) changed enforce_max_runtime to read + # from task_runs.started_at (per-attempt) rather than + # tasks.started_at (lifetime), we need to backdate BOTH to + # guarantee the timeout fires regardless of which column the + # query pulls from. with kb.write_txn(conn): + long_ago = int(time.time()) - 30 conn.execute( "UPDATE tasks SET started_at = ? WHERE id = ?", - (int(time.time()) - 30, tid), + (long_ago, tid), + ) + conn.execute( + "UPDATE task_runs SET started_at = ? " + "WHERE id = (SELECT current_run_id FROM tasks WHERE id = ?)", + (long_ago, tid), ) before = kb.get_task(conn, tid) assert before.consecutive_failures == 0