interrupt can take a long time, it should be immediate

[dmt4]

Using deepseek v4 flash from opencode go, sometimes I find myself waiting for quite a bit after pressing 'esc' while the model goes off on a tangent, pressing repeatedly or doing ctrl+c doesn't help either. On an rare occasion esc works quickly.

I think it should really be immediate.

The TUI can get quite slow after a while and when under load from the model pouring text, through I don't think this is the reason for interruption not to work because the TUI does acknowledge it quickly, then the acknowledgement indicator soon disappears though so not really sure.

[dmt4]

Forgot to say, version used was git commit 381306e, however it has been an issue for a while.

[1jehuang]

Investigated the full cancel path end to end and landed a hardening fix on master in bda54d8.

How cancel works today: Esc sends Request::Cancel, which the server dispatches before writing the Ack (so heavy streaming can't delay it), fires the session's lock-free InterruptSignal, waits 500ms for cooperative exit, then hard-aborts the turn task (crates/jcode-app-core/src/server/client_lifecycle.rs:2737). The agent's stream loop and tool-wait select both park on InterruptSignal::notified() (crates/jcode-app-core/src/agent/turn_streaming_mpsc.rs:328,1282).

What we found: InterruptSignal::notified() (crates/jcode-agent-runtime/src/lib.rs) created the tokio Notified future and checked the fired flag before awaiting. Notify::notify_waiters() wakes only registered waiters and stores no permit, so any gap in registration loses the wakeup entirely - and a lost wakeup there parks the cancel path until an unrelated event (e.g. the next stream token or keepalive) arrives, which matches your symptom of the interrupt being acknowledged and then apparently ignored. The future is now explicitly enable()d before the flag check, with a 2000-iteration race-hammer regression test plus a test pinning the tokio semantics.

Also worth noting: several interrupt-path fixes landed since the commit you reported on (381306e), including pre-Ack cancel dispatch and a lock-free cancel handle for busy sessions.

Could you retest on the next release (or a master build)? If Esc still takes long, the server logs now have detailed SERVER_INTERRUPT_* timing lines (in ~/.jcode/logs/) - a snippet from around a slow interrupt would pinpoint any remaining latency precisely.

[dmt4]

Tried 7b90fd6 which contains commits you mentioned and it seems much the same: pressing esc while model outputs thinking content leads to "Interrupting ..." appearing for 3-4s just above the prompt line then disappearing, after this it is as if nothing happened, the model keeps going at full speed. Eventually when it does stop, "Interrupted [xN]" appears (N happened to be 66 this time).

The log has this repeating ~N times:

[2026-07-04 07:38:58.797] [INFO] REMOTE_INTERRUPT_SEND_START kind=cancel id=61 trigger=keyboard_escape session=Some("session_jaguar_1783124526610_90e7e38e71d0a7d3") client_instance=Some("client_1783124526239_1202838306699897800") json_bytes=26
[2026-07-04 07:38:58.798] [INFO] REMOTE_INTERRUPT_SEND_OK kind=cancel id=61 trigger=keyboard_escape session=Some("session_jaguar_1783124526610_90e7e38e71d0a7d3") client_instance=Some("client_1783124526239_1202838306699897800") writer_wait_ms=0 write_ms=0 total_ms=0
[2026-07-04 07:38:58.798] [INFO] SERVER_INTERRUPT_REQUEST_DECODED kind=cancel id=61 session=session_jaguar_1783124526610_90e7e38e71d0a7d3 client_processing=false message_id=None has_task=false line_bytes=26
[2026-07-04 07:38:58.798] [INFO] SERVER_INTERRUPT_CANCEL_PRE_ACK_DISPATCH id=61 session=session_jaguar_1783124526610_90e7e38e71d0a7d3 ack_queued=true decoded_to_dispatch_ms=0
[2026-07-04 07:38:58.798] [INFO] SERVER_INTERRUPT_CANCEL_RECEIVED request_id=Some(61) session=session_jaguar_1783124526610_90e7e38e71d0a7d3 control_session=session_jaguar_1783124526610_90e7e38e71d0a7d3 client_processing=false message_id=None has_task=false decoded_age_ms=Some(0)
[2026-07-04 07:38:58.798] [WARN] SERVER_INTERRUPT_CANCEL_NO_LOCAL_TASK request_id=Some(61) session=session_jaguar_1783124526610_90e7e38e71d0a7d3 control_session=session_jaguar_1783124526610_90e7e38e71d0a7d3 client_processing=false message_id=None; signalling session cancel handle anyway
[2026-07-04 07:38:58.798] [INFO] SERVER_INTERRUPT_CANCEL_EVENTS_EMITTED request_id=Some(61) session=session_jaguar_1783124526610_90e7e38e71d0a7d3 interrupted=true done_id=None total_ms=0
[2026-07-04 07:38:58.798] [INFO] SERVER_INTERRUPT_CANCEL_PRE_ACK_DONE id=61 session=session_jaguar_1783124526610_90e7e38e71d0a7d3 dispatch_ms=0 total_since_decode_ms=0

then at the end when it finally stopped there are ~N of these:

[2026-07-04 07:46:20.313] [INFO] REMOTE_INTERRUPT_EVENT_RECEIVED kind=interrupted session=Some("session_jaguar_1783124526610_90e7e38e71d0a7d3") current_message_id=None is_processing=false status=Idle streaming_text_bytes=0 pending_soft_interrupts=0 queued_messages=0

notice the it took ~7-8min. In this time the agent was spewing thinking content, calling tools etc..

[1jehuang]

Landed a deeper fix on master in 9c1ca3e1 (merged in e2a50251), directly from your log evidence.

Root cause found: your logs showed SERVER_INTERRUPT_CANCEL_NO_LOCAL_TASK with has_task=false on every Esc. The cancel was firing the InterruptSignal held by your connection's control handle, but after a reattach/reload (or for server-initiated and headless turns) that signal can be a different instance from the graceful_shutdown signal the streaming turn actually polls. Firing the stale instance did nothing, so the client showed "Interrupting..." while the model kept generating, and each extra Esc just stacked another Interrupted [xN].

Fix: a process-global turn cancel registry. Every turn registers its own cancel signal at turn start (RAII, auto-unregistered and reset when the turn ends), and request_cancel now fans out to every registered signal for the session in addition to its own handle. So the cancel reaches the in-flight provider stream no matter which handle instance received it. New log line to look for: SESSION_CANCEL_ACTIVE_TURN_SIGNALS_FIRED.

Validated with a regression test reproducing exactly your scenario (streaming turn + stale control-handle signal, cancel must abort promptly). Would appreciate a retest on a build containing 9c1ca3e1 next time you're on deepseek via opencode go.

[dmt4]

Just fetched and don't see 9c1ca3e1 neither e2a50251.

I think is not specific to opencode go or ds4 flash, today was running gemma4 31b myself and was the same story.