Regression: background job completion can be mislabeled as user interruption

[yxlyx]

Summary

Regression of #134 on graff 0.0.284: the conversation displayed [response interrupted by user] twice even though the user did not press Esc, click cancel, or send input to interrupt either response.

This occurrence appears correlated with an asynchronous background-job completion notification. The job output had already been consumed through bash_output, but a separate job-completion message was subsequently injected, after which assistant responses were replaced by the user-interruption marker.

Environment

• graff: 0.0.284
• macOS: 26.4.1
• architecture: arm64
• model: gpt-5.6-sol

Observed sequence

1. A background Bash verification job was started.
2. The agent used bash_output with a blocking wait.
3. The job exited successfully and bash_output returned its result.
4. A separate asynchronous [job ... exited 0 ...] notification was injected afterward, despite the output already having been consumed.
5. The assistant generated a response, but the conversation showed [response interrupted by user].
6. The same false marker appeared again on the next attempted assistant response.
7. The user explicitly confirmed they did not interrupt either response.

Sanitized trace evidence

• The blocking bash_output tool event completed successfully after about 341 seconds with is_error: false.
• The following WebSocket request connected normally, received frames, and completed.
• The following main API event completed with is_error: false.
• The recipe outcome was recorded as success: true.
• There is no structured user_interrupt, esc, cancel, or stream_stall event around the false interruption.
• An earlier WebSocket idle re-anchor/reconnect also completed successfully and was not recorded as an API error.

Raw trace IDs, session IDs, filesystem paths, usernames, and application data are intentionally omitted.

Expected behavior

• Only an actual user Esc/cancel action should produce [response interrupted by user].
• An asynchronous job-completion notification must not cancel or overwrite an in-progress assistant response.
• If an internal race or transport condition ends a response, label it as a harness/system error rather than a user interruption.
• Record a structured trace event identifying the actual interruption source.

Actual behavior

A completed assistant response was replaced by [response interrupted by user] twice, with no user cancellation and no corresponding interruption event in the trace.

Possible regression area

This may be a race between background-job completion injection and response finalization. It is related to #134, which was fixed in 0.0.194+, but this recurrence is on 0.0.284 and does not show a stream_stall trace event.

[justrach]

Landed in #732 (on main, next release): every setter of the cancel flag now records its source, a turn that ends cancelled with no recorded source is labelled [response ended early: cancelled by the harness, not the user] instead of a user interrupt, and the trace notes interrupted source=… either way. The raw stdin scanner also stops reading a terminal's OSC reply as an Esc keypress, and the job-exit notice injected after the output was already consumed was removed by #727.

Not claimed: the trigger of the false cancel itself was not reproducible from the report (the desktop bridge has no cancel path at all). If it happens again on a build with #732, the trace's interrupted source= line will say which path raised it — please paste just that line here. Leaving this open until then.

[justrach]

Fixed in 0ee0981 on release/v0.0.288, preserving the existing cancellation-source fix. Completion consumption is synchronized with notification queuing, preventing consumed jobs from resurrecting wakes. Lifecycle and cancellation-attribution regressions passed.