A workflow crashes. You ask the coding agent to resume it. Before a fix merged into the QwenLM/qwen-code repository on September 18, a missing record of the old work could cause every agent to run again under the old run ID. The name suggested continuity; the execution started over.
The public report behind the fix describes a second cost: after a process restart, the same path could erase a saved reference to the workflow's source. The repair matters to anyone supervising a sequence of delegated tasks. “Continue” is a consequential instruction when doing the work again can spend more money, repeat a tool action, or muddy the account of what already happened. Those are possible consequences of rerunning agents, not documented incidents in this report.
The file that changes the meaning of a button
Qwen's workflow journal records agent activity and completed results. On replay, the runner can reuse a saved result instead of dispatching that agent again. But the old loader treated a missing file like an empty replay. A run with no surviving journal therefore looked much like a run that had not yet cached any work.
The merged change makes the distinction explicit. With storage configured, a missing or unreadable journal now stops a resume before dispatch. A user who wants a fresh run must request one without the old resume identifier. An existing, empty journal remains accepted for compatibility with older runs. This is a narrower promise than “nothing can ever rerun.”
The repair also looks beyond memory. A process-local registry disappears when the process exits. The runner now consults the persisted snapshot when checking that a resumed workflow still carries its original source reference. Otherwise, losing the journal's source record after a restart could let a new settlement overwrite the saved attribution. The same snapshot helps restore an inline script if a resume attempt fails to start.
A recoverable run still has to be found
Refusing a false continuation solves only half the operator's problem. A run with useful journal entries could disappear from the workflow list after a crash because its ordinary history snapshot was written at settlement—the point it never reached.
A second September 18 change adds a checkpoint beside the journal when the run registers. It records enough about the attempt, including its process, host and script, for a later process to identify an interruption. On a subsequent interactive startup, or before a new Agent Client Protocol session loads workflow history, an eligible checkpoint becomes a failed historical run with an interruption explanation.
That “failed” label is useful. It gives the supervisor a visible unfinished job and, where a journal is available, a way to request a resume. It does not quietly restart work. Headless runs do not perform this discovery; a later interactive or ACP start does.
The claiming code is deliberately cautious about ownership. It leaves another host's checkpoint alone, checks whether the writer still exists, and avoids a run held by a current session or a starting resume. It rereads the checkpoint before claiming it and recognizes a snapshot that already covers the attempt. A reused process ID can delay discovery rather than establish that the old work has failed.
The restart is still a boundary
The first reading of this pair is an appealing crash-recovery story. The implementation supports a more useful, less sweeping conclusion: Qwen is improving what a supervisor can know and request after a crash. Checkpoint writes are best-effort. The lock coordinates sessions within one process, not a distributed recovery service. A recorded result can be replayed, but an external action whose result never reached the journal is not thereby proven safe to repeat.
We inspected the merged runner, journal, checkpoint and regression-test changes; we did not reproduce a live process-kill recovery or establish a released package containing both patches. The public contribution trail ties the two changes to successive parts of the same restart work. It does not establish an exactly-once guarantee, automatic resumption, or every planned history operation.
For an operator evaluating this source, the revealing test is a disposable two-step workflow: interrupt it after the first result is saved, inspect the recovered history, and count which steps actually run after an explicit resume. Then remove the journal and confirm refusal. A restart feature earns trust when it can both find unfinished work and admit that the evidence needed to continue is gone.