Sign up
View stargazersSign up

[Bug]: Stop gives no pending feedback, so repeat clicks turn into Resume and send "Continue where you left off"#20404

opened24d agobyIiagorockel

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

  1. Start a run, ideally on a thread that has delegated tasks, where Stop takes several seconds.
  2. Click Stop.
  3. Nothing changes, so click it again a few times.

Expected behavior

The click immediately changes the button to a disabled "Stopping…" state until the run actually settles, so it's clear the request was received. Clicks while it's stopping do nothing. After the run stops, the first click should not quietly resume it.

Actual behavior

The button looks the same until the provider confirms the interrupt. Once the run is interrupted, the same button acts as resume. The extra clicks then send "Continue where you left off" and start a new run, and I have to stop that one too. The timeline ends up with "Run interrupted by user", then the automatic "Continue where you left off", then "Run interrupted before provider start" (screenshot attached).

Related: #8618 (same "Stopping…" request, closed), #20342 (likely cause of the slow stop), #17184 (another path that sends "Continue where you left off" automatically)

Impact

Minor bug or occasional failure

Version or commit

0.1.1-nightly.20261016.3203

Environment

macOS 26.6.2, desktop app (Nightly), Claude provider

Logs or stack traces

shell
1Timeline from local server traces + statev2.sqlite (UTC, thread 1bb52ab2-…, Claude provider):
2
322:18:31.747 Stop click #1 → EnvironmentCommands.interruptThreadTurn (818 ms round-trip)
422:18:32.564 ClaudeAdapterV2.interruptTurn starts (1412 ms, Success)
522:18:34.371 run 119 → interrupted (~2.6 s after the click, no UI change meanwhile)
622:18:34.933 repeat click: user message "Continue where you left off." (creationSource: web) → run 120 starts
722:18:35.118 Stop click again → interruptThreadTurn (116 ms)
822:18:35.572 run 120 → interrupted ("Run interrupted before provider start")
9
10Same pattern 15 min earlier in the same thread:
1122:03:53.122 run 114 → interrupted
1222:03:53.754 "Continue where you left off." → run 115
1322:03:54.416 run 115 → interrupted
14
156 auto-sent "Continue where you left off." messages in my local state DB overall. No errors; every step succeeds, so there's no stack trace.

Screenshots, recordings, or supporting files

image.png

Workaround

No response

JJulius Marminge24d ago

Note

Grok responding on behalf of Julius.

I can confirm this on main: the web composer has no pending-stop state.

  • In ComposerPrimaryActions.tsx, the Stop button only disables on !canOperateThread. Clicking it calls onInterrupt() without awaiting it and sets no local "stopping" flag, so the button looks the same until the server reports the run as interrupted.
  • Once canInterrupt goes false, the same slot renders the send button in "Resume thread" mode (showResume, onClick={onResume}). Clicks that were meant for Stop land on Resume, and Resume sends "Continue where you left off".

This is separate from what makes the stop itself slow. That's tracked in #20342 (walking the delegated-task tree) and in the Claude interrupt PRs #16419 / #17498. Speeding those up shrinks the window but doesn't close it. #8618 asked for "Stopping…" feedback, but it was closed for a server-side stuck-state fix, not this UI gap. #17184 is a different automatic-continue path (cancelled /compact).

Possible directions:

  • Disable the Stop button and show it as "Stopping…" from the click until the run settles.
  • Ignore Resume clicks for a short moment right after a stop, or put Resume somewhere other than where Stop was.

Thanks for the timeline. The 0.6 s gap between the interrupt and the auto-sent message made this easy to pin down.