fix(first-run-tour): stop promising a result once acceptance is lost (#15172)

Stacked on #15091 — base is `fix/14619-tour-unaccepted-run`, merge after
it.

#15091 gave the first-run tour a 15s acceptance deadline, which covers a
submission the backend refuses outright. It left one hole: a run that
*was* accepted and then loses its job without an outcome. Two live paths
do that, and **neither is the mid-run credits path this description
originally led with** — thanks @benjcooley for catching that:

| path | what it leaves behind | covered before this PR? |
| --- | --- | --- |
| accepted job dropped with **no status ever written** — the cloud
"waiting for a machine" job cancelled or reconciled away | nothing | ❌
no branch can fire |
| `handleServiceLevelError` ("Job has stagnated") — drops the job,
records a prompt error, never touches `workflowStatus` | a stale
`running` | ❌ the stale `running` shadowed the error branch |
| ~~mid-run credits (`handleAccountPreconditionError`)~~ | ~~stale
`running`~~ | ✅ **already covered** — #15161 clears the status, so it
ends via the existing `undefined`-after-`running` branch |

In the uncovered cases `runState` sits on `generating` forever and the
card keeps promising "Hang tight, your result lands right here the
moment it's ready."

The controller had two disarms and no re-arm. This makes losing
acceptance a signal in its own right: extend the existing
`tourRunAccepted` watcher so true -> false fails the run when it is
still `generating`.

```ts
watch(tourRunAccepted, (accepted) => {
  if (accepted) stopAcceptDeadline()
  else if (runState.value === 'generating') runState.value = 'failed'
})
```

No re-armed deadline — this is immediate, not a second timer.

The `'generating'` gate is what keeps healthy runs safe: every run
leaves the queue when it finishes. `handleExecutionSuccess` and
`handleExecutionError` write the terminal status and call
`resetExecutionState` in the same synchronous handler, and the status
watcher is registered before this one, so a finished run has already
left `generating` by the time this fires. Test 3 below covers exactly
that tick.

Tests, in the existing `'a run behind a dropped socket'` describe:
- accepted job removed with no status -> `failed`
- accepted job, status `running`, removed (the stagnation case) ->
`failed`
- accepted job, status `completed` written in the same tick as the
removal -> stays `succeeded`
- accepted job, status `failed`, then removed -> stays `failed`

The first two fail on the base branch (`expected 'generating' to be
'failed'`). Of the last two terminal-status guards, **only the
`completed` one discriminates** — ungated, the `failed` case writes
`'failed'` over `'failed'` and still passes. It is kept as documentation
of intent, not as a guard; the earlier claim that both pinned the gate
was wrong.

Two tests added in review:

- `stays failed when an unrelated workflow churns the status map` — pins
the transition gate below. Fails without it (`expected 'generating' to
be 'failed'`).
- `gives up on a stagnated job that leaves an error and a stale status`
— the other half of the stagnation path. Documents it; does not
discriminate the gate.

**Review fix:** the status watcher's `status === 'running'` branch was
unconditional, and its source re-evaluates whenever the `workflowStatus`
map is replaced (`mutateStatus` swaps the whole map, so *any* workflow's
change re-runs it) or an error flag flips. With a stale `running`
sitting there, each re-evaluation put the card back on "your result
lands right here" after this watcher had already failed the run. It is
now gated on an actual transition into `running`, which also removes the
registration-order dependency the old comment overclaimed away.

Complementary to #15161 (**merged 2026-08-13**), which fixes the same
user-visible symptom from the store side by clearing the stale status.
Independent of it: this is the controller refusing to promise regardless
of whether the store cleans up. Both are wanted; neither duplicates the
other.

Requested by @benjcooley in review on #15091 (acceptance-loss watch for
the mid-run credits variant) and by CodeRabbit (acceptance-loss
coverage, terminal statuses stay terminal).

## Tests
- 58 unit tests green in `useFirstRunTourController.test.ts` (54
existing + 4 new), full-file and each new test in isolation.
- `pnpm lint`, `pnpm typecheck`, `pnpm format:check` pass.

---------

Co-authored-by: Connor Byrne <c.byrne@comfy.org>

Author: christian-byrne

src/renderer/extensions/firstRunTour/tour/useFirstRunTourController.test.ts

@@ -202,6 +202,12 @@ function acceptRun(workflow: unknown) {
   return nextTick()
 }
 
+/** The queue letting a job go, which `resetExecutionState` does silently. */
+function removeRun() {
+  mocks.queuedJobs.value = {}
+  return nextTick()
+}
+
 function finishRun(workflow: unknown, status: string) {
   mocks.workflowStatus.value = new Map(mocks.workflowStatus.value).set(
     workflow,
@@ -506,6 +512,110 @@ describe('useFirstRunTourController', () => {
         'the grace timer must not clobber an outcome that arrived before it fired'
       ).toBe('succeeded')
     })
+
+    it('stops promising a result once the queue lets go of its job', async () => {
+      await tourOnRunStep()
+      mountRunButton('queue-button', () => {}).click()
+      await acceptRun(TOUR_WORKFLOW)
+
+      await removeRun()
+
+      expect(
+        mocks.runState.value,
+        'an accepted job that leaves without an outcome leaves the card waiting on a result nobody will send'
+      ).toBe('failed')
+    })
+
+    it('stops promising a result when a running job is dropped mid-run', async () => {
+      // `handleServiceLevelError` ("Job has stagnated") is the live path: it
+      // drops the job and records a prompt error but never touches
+      // `workflowStatus`, so the `running` from `handleExecutionStart`
+      // outlives the run and no status change reports the end.
+      //
+      // Deliberately not the mid-run credits path — #15161 made
+      // `handleAccountPreconditionError` clear the status, so that one ends
+      // via the `undefined`-after-`running` branch without this watcher.
+      await tourOnRunStep()
+      mountRunButton('queue-button', () => {}).click()
+      await acceptRun(TOUR_WORKFLOW)
+      await finishRun(TOUR_WORKFLOW, 'running')
+
+      await removeRun()
+
+      expect(
+        mocks.runState.value,
+        'a run cut short for credits keeps its running status, so losing the job is the only signal left'
+      ).toBe('failed')
+    })
+
+    it('keeps a completed run that drops out of the queue as it finishes', async () => {
+      await tourOnRunStep()
+      mountRunButton('queue-button', () => {}).click()
+      await acceptRun(TOUR_WORKFLOW)
+
+      // `handleExecutionSuccess` reports the outcome and drops the job in one
+      // tick, so both land before either watcher runs.
+      void finishRun(TOUR_WORKFLOW, 'completed')
+      await removeRun()
+
+      expect(
+        mocks.runState.value,
+        'every healthy run leaves the queue when it finishes; failing those would fail every run'
+      ).toBe('succeeded')
+    })
+
+    it('keeps a failed run that leaves the queue after reporting', async () => {
+      await tourOnRunStep()
+      mountRunButton('queue-button', () => {}).click()
+      await acceptRun(TOUR_WORKFLOW)
+      await finishRun(TOUR_WORKFLOW, 'failed')
+
+      await removeRun()
+
+      expect(
+        mocks.runState.value,
+        'a reported outcome is the last word; losing the job afterwards says nothing new'
+      ).toBe('failed')
+    })
+
+    // Pins the transition gate on the status watcher. The stagnation path
+    // leaves `running` in `workflowStatus` forever, and that source
+    // re-evaluates whenever the map is replaced for *any* workflow. Without
+    // the gate the stale `running` is re-read and the card goes back to
+    // promising a result it has already given up on.
+    it('stays failed when an unrelated workflow churns the status map', async () => {
+      await tourOnRunStep()
+      mountRunButton('queue-button', () => {}).click()
+      await acceptRun(TOUR_WORKFLOW)
+      await finishRun(TOUR_WORKFLOW, 'running')
+
+      await removeRun()
+      expect(mocks.runState.value).toBe('failed')
+
+      await finishRun(OTHER_WORKFLOW, 'running')
+
+      expect(
+        mocks.runState.value,
+        'another workflow starting is not this run coming back from the dead'
+      ).toBe('failed')
+    })
+
+    // The other half of the stagnation path: the prompt error it records must
+    // still be able to end the run while the stale `running` sits there.
+    it('gives up on a stagnated job that leaves an error and a stale status', async () => {
+      await tourOnRunStep()
+      mountRunButton('queue-button', () => {}).click()
+      await acceptRun(TOUR_WORKFLOW)
+      await finishRun(TOUR_WORKFLOW, 'running')
+
+      mocks.executionErrors.hasPromptError = true
+      await removeRun()
+
+      expect(
+        mocks.runState.value,
+        'a stagnated run reports an error and abandons the job; the status it leaves behind is not news'
+      ).toBe('failed')
+    })
   })
 
   describe('run outcome', () => {

src/renderer/extensions/firstRunTour/tour/useFirstRunTourController.ts

@@ -75,7 +75,16 @@ function useFirstRunTourControllerInternal() {
     ],
     ([status, refused], previous) => {
       if (status !== undefined) stopAcceptDeadline()
-      if (status === 'running') runState.value = 'generating'
+      // Only an actual transition into `running` starts the wait. This source
+      // re-evaluates whenever the `workflowStatus` map is replaced — which
+      // `mutateStatus` does for *any* workflow — or whenever an error flag
+      // flips. Paths that drop a job without clearing its status leave
+      // `running` behind forever (`handleServiceLevelError` is the live one),
+      // so an unconditional branch here would re-read that stale value and put
+      // the card back on "your result lands right here" after the watcher
+      // below has already failed the run.
+      if (status === 'running' && previous?.[0] !== 'running')
+        runState.value = 'generating'
       else if (status === 'completed') runState.value = 'succeeded'
       else if (status === 'failed') runState.value = 'failed'
       // A refused run never queues; a stopped one drops its status rather than
@@ -118,9 +127,27 @@ function useFirstRunTourControllerInternal() {
    * Acceptance is not the only disarm. `resetExecutionState` drops a job from
    * `queuedJobs` without clearing its status, so a run can report a status
    * while this reads false. A refusal produces neither signal.
+   *
+   * Losing acceptance is itself a signal, not a re-armed deadline. Two paths
+   * drop the job without ever writing an outcome:
+   *
+   * - an accepted job that disappears with **no status written at all** — the
+   *   cloud "waiting for a machine" job that is cancelled or reconciled away
+   * - `handleServiceLevelError` ("Job has stagnated"), which drops the job and
+   *   records a prompt error but never touches `workflowStatus`, so the
+   *   `running` written by `handleExecutionStart` outlives the run
+   *
+   * Not the mid-run credits path: #15161 made
+   * `handleAccountPreconditionError` clear the status, so that one already
+   * ends via the `undefined`-after-`running` branch above.
+   *
+   * A finished run leaves the queue too, but reports a terminal status in the
+   * same flush, and the terminal branches above overwrite unconditionally — so
+   * the outcome wins whichever watcher runs first.
    */
   watch(tourRunAccepted, (accepted) => {
     if (accepted) stopAcceptDeadline()
+    else if (runState.value === 'generating') runState.value = 'failed'
   })
 
   let acceptTimer: ReturnType<typeof setTimeout> | undefined