[bug]: webv2 resubmits a run indefinitely after a 500 on enqueue; the run is hidden from the Queue panel and survives reloads #9854

Is there an existing issue for this problem?

• I have searched the existing issues

Install method

Invoke's Launcher

Operating system

Windows

GPU vendor

Nvidia (CUDA)

GPU VRAM

12 GB

Version number

7.0.0-alpha.2 (code paths below unchanged on main at 723d600)

Browser

Chrome 154.0.8037.98 (Official Build) (64-bit)

What happened

When POST /api/v1/queue/default/enqueue_batch returns 500 for a workflow run, webv2 keeps resubmitting the same run indefinitely. The server log gets a full traceback each time, several per second while the tab is open.

The trigger in my case was #9852: a graph that crashes server-side validation (fixed in #9853). Any enqueue request that deterministically returns 500 behaves the same way.

Three things make this hard to get out of:

1. 5xx is always treated as transient. In features/queue/runtime.ts, a 4xx response (except 408/429) marks the run failed (around line 1390). Any other error re-queues the run key and calls scheduleRetry() (line 1403), with no attempt limit. A 500 caused by the request content never succeeds, so the loop never ends.
2. The run is invisible. While it was being retried, the run did not appear in the Queue panel, under All or Active, so there was nothing to cancel. The backend queue was empty too, since every enqueue was rejected.
3. It survives reloads and restarts. The run is kept in IndexedDB (invokeai:v7:webv2:workbench…, store queueRuns) and reconciled on load. Closing the tab, restarting the server and reopening the project all start the retries again. The only fix I found was deleting the entries from queueRuns (and queueReceiptAcks) by hand in DevTools.

Keeping pending runs across reloads makes sense, so work isn't lost. The problems are the unbounded retry of a deterministic failure, and that the user can't see or cancel the run.

What you expected to happen

• After a small number of 5xx responses to the same submission, the run is marked failed and shows the server error, as it would for a 4xx.
• Any run the client is submitting or retrying is listed in the Queue panel with its state, and can be cancelled from there.

How to reproduce the problem

1. On a build without fix(graph): reject mismatched collector items for union collection inputs #9853: in a workflow, connect two Integer nodes to a Collect node's item, and Collect collection to a Metadata node's items. Press Invoke.
2. The server logs TypeError: issubclass() argument 2 cannot be a parameterized generic in graph_validation.py repeatedly while the tab is open.
3. The Queue panel shows no entry for the run.
4. Reload the page or restart the server: the retries start again.
5. DevTools → Application → IndexedDB → invokeai:v7:webv2:workbench… → queueRuns contains the run. Deleting it and reopening the tab stops the retries.

Additional context

Server-side counterpart: #9852 / #9853. That fix turns this particular case into a 422, which webv2 already handles. The client behaviour remains for any other deterministic 500.