[Bug] Resume workflow skips journal cache entries and re-runs completed agents

Status Open
Reported on v2.1.237
Maintainer reply None cached
Activity 0 comments · opened Aug 20, 2026

Bug Description
Setup: Dynamic multi-agent workflow (Workflow tool), run ID wf_d45e22cc-13c, 2026-08-20, Europe/Berlin. 34 agents across 4 phases. Timeline: - Run 1 (10:53): user paused at ~11:06; 6 in-flight agents lost their work entirely (no partial state) — expected per docs, but costly (~3.1M weighted tokens redone). - Run 2 (12:56, resumeFromRunId): replayed run-1 results correctly, completed 33/34 agents incl. the final synthesis (result written to journal.jsonl); last agent failed at 13:19 on the 5h session limit. - Run 3 (17:50, same scriptPath + resumeFromRunId): expected to replay all 33 journaled results and re-run only the one failed agent. Instead it re-ran 5 panel agents + 1 judge whose completed results WERE in journal.jsonl (as {"type":"result","key":"v2:…"} lines), i.e. it resumed from the second-to-last state. Stopped manually after ~2 min; ~3.6M price-weighted input-equivalent tokens (12.6M raw) burned — about a quarter of a fresh 5h window. Observation: run-1 journal entries have no "key" field, run-2/3 entries use "v2:…" keys; run 3's newly started agents got v2 keys that did not match the recorded v2 keys for identical (prompt, opts). Also, run 3 started the final sequential agent concurrently with mid-pipeline agents, which suggests inconsistent partial replay. Expectation: resume should be idempotent — identical script + args must hit the journal cache for every recorded result, regardless of harness restarts between runs.

Environment Info

  • Platform: darwin
  • Terminal: Apple_Terminal
  • Version: 2.1.237
  • Feedback ID: 0db263fa-443f-49fc-be84-1c0a26bda01d

Errors

[]

View original on GitHub ↗