fix(multiuser): fix cross-user queue badge, progress bar, and gallery hijacking

[lstein]

This PR fixes three related multiuser-mode issues that all stem from how socket events are (correctly) isolated per user, while frontend state was assuming it sees every relevant event.

1. Queue badge shows the wrong global total

Reproduction: User A queues 2 jobs; User B immediately queues 2 jobs. User A's badge shows 2/2 (wrong — should be 2/4); User B's shows 2/4 (correct).

Root cause: queue_item_status_changed and batch_enqueued events are emitted only to the owning user's socket room (privacy — they carry unsanitized user_id/batch_id/session_id). The frontend badge only refetches the global queue status in response to those events, so a non-admin only learns about queue changes from their own jobs. Whoever queued first captured the global total before the other user's jobs existed, then stopped refetching.

2. Progress bar animates indefinitely

Same root cause: once a user's own jobs finish they get no further signal, so the global in_progress count freezes at a non-zero value. ProgressBar.tsx reads that frozen in_progress > 0 (with lastProgressEvent null) and stays isIndeterminate forever.

Fix for 1 & 2

Broadcast a content-free queue_counts_changed event to the whole queue room whenever counts change (a status transition or an enqueue). It carries only queue_id — no user_id, batch_id, session_id, or counts — so every subscriber simply refetches GET /queue/{id}/status, which already redacts per-user data. Nothing private is leaked. It never fires on high-frequency invocation-progress events.

• invokeai/app/api/sockets.py — _broadcast_queue_counts_changed() helper, called from the status-changed and batch-enqueued branches of _handle_queue_event.
• invokeai/frontend/web/src/services/events/types.ts — type the new event.
• invokeai/frontend/web/src/services/events/setEventListeners.tsx — handler invalidating only SessionQueueStatus.

3. Another user's image hijacks an admin's gallery

Reproduction: Admin (User A) and unprivileged User B logged in on separate browsers. Any image B renders switches A's selected board to B's board and displays B's image. Does not happen between two unprivileged users.

Root cause: Admins are in the admin socket room and receive invocation_complete events for every user. addImagesToGallery ran for all of them, inserting other users' images into the admin's gallery and auto-switching the admin's selected board.

Fix for 3

Gate addImagesToGallery on ownership: when an authenticated user is present and the event's user_id differs from theirs, skip the gallery insertion and auto-switch. In single-user mode there is no authenticated user, so the original behavior is preserved.

• invokeai/frontend/web/src/services/events/onInvocationComplete.tsx

Testing

• Manually verified with two users (2 + 2 jobs): both badges settle on 2/4, count down together, and clear with no lingering spinner.
• Manually verified admin no longer has their board switched when another user generates an image.
• tsc --noEmit, eslint --max-warnings=0, prettier --check all pass.
• ruff check and ruff format --check pass.

🤖 Generated with Claude Code

[JPPhoto]

I found one thing so far.

• invokeai/invokeai/frontend/web/src/services/events/onInvocationComplete.tsx:262

  The new cross-user guard only wraps addImagesToGallery() at lines 48-61, but admin clients still process another user's invocation_complete before that guard. The backend sends every invocation event to the admin room in invokeai/invokeai/app/api/sockets.py:304-316, and InvocationCompleteEvent carries the owner user_id. When an admin receives another user's completion event, the handler still reads and upserts $nodeExecutionStates at lines 265-280, clears canvas workflow integration processing at lines 283-284, and clears $lastProgressEvent at line 289. This can mark the admin's local workflow nodes complete, append another user's outputs to matching node IDs, or stop the admin's canvas workflow integration spinner even though the event was not theirs. Common node IDs make this realistic, and getUpdatedNodeExecutionStateOnInvocationComplete() creates state even when one did not exist.

  To expose this issue, add a frontend vitest for buildOnInvocationComplete that sets auth.user.user_id to an admin user, seeds $nodeExecutionStates or canvas integration processing state, invokes the handler with data.user_id for a different user, and asserts that node execution state, canvas processing state, gallery state, and $lastProgressEvent are not mutated.

[lstein]

Thanks @JPPhoto — good catch, that was a real hole. The cross-user guard only wrapped addImagesToGallery(), so an admin receiving another user's invocation_complete via the admin room still ran the node-execution-state upsert, clearCanvasWorkflowIntegrationProcessing(), and the $lastProgressEvent.set(null) at the end of the handler.

Fixed in 2f7547a:

• Hoisted the guard to the top of the returned handler in onInvocationComplete.tsx, so a foreign event returns before any side effect (node execution state, canvas integration processing, gallery, or $lastProgressEvent). Removed the now-redundant inner guard in addImagesToGallery().
• Single-user mode is unchanged: when there's no authenticated user (selectCurrentUser is null) every event is the local user's own and falls through as before.
• Added onInvocationComplete.test.ts as you suggested: an admin receiving another user's event asserts no $nodeExecutionStates upsert, no dispatch, and $lastProgressEvent untouched — plus own-event and single-user positive controls.

Also merged latest main, which had landed a superseding version of the backend badge fix (sanitized companion events via skip_sid instead of the queue_counts_changed nudge). I deferred sockets.py and the routing tests entirely to main's implementation, so this PR is now just the frontend cross-user isolation work.

[JPPhoto]

@lstein I found one issue:

• invokeai/frontend/web/src/services/events/setEventListeners.tsx:180: Cross-user filtering remains incomplete and occurs too late. Admin sockets receive every user's invocation and queue-status events from invokeai/app/api/sockets.py:320-343. The ownership check at invokeai/frontend/web/src/services/events/onInvocationComplete.tsx:261 runs only after workflowExecutionCoordinator.onInvocationComplete() has recorded the foreign completion at invokeai/frontend/web/src/services/events/workflowExecutionCoordinator.ts:179-195. Foreign invocation_started, invocation_progress, and invocation_error events remain unfiltered at lines 180-210, allowing them to create or overwrite node execution state and replace $lastProgressEvent. Foreign full queue_item_status_changed events also reach admins without the redacted sentinel and can replace activeWorkflowQueueItemId, reset the admin's node states, or reconcile another user's queue item at workflowExecutionCoordinator.ts:198-233. Another user's workflow can therefore still corrupt an admin's local execution and progress state despite the new completion-handler guard. The added test calls buildOnInvocationComplete() directly, bypassing the coordinator and socket listeners where these mutations occur. To expose this issue, add a test that emits another user's started, progress, error, complete, and full queue-status events through setEventListeners for an authenticated admin and asserts that workflow coordinator state, node execution states, canvas processing state, completed-invocation tracking, and $lastProgressEvent remain unchanged.

[lstein]

Thanks @JPPhoto — you're right on every count, and the root cause was that I put the check in the wrong layer. Fixed in 529c0c2 by moving it to the socket listener, before the coordinator ever sees the event.

setEventListeners.tsx now has a single isForAnotherUser() gate:

• invocation_started / invocation_progress / invocation_error / invocation_complete: foreign events are dropped outright, so they can't create or overwrite node execution state, clear the canvas integration spinner, replace $lastProgressEvent, or record completed-invocation keys. This closes the ordering hole you identified — the guard now runs before workflowExecutionCoordinator.onInvocation*() rather than after.
• queue_item_status_changed: a foreign full event (what admins get, since the sanitized companion skips owner/admin sids) now takes the same path as the redacted companion — invalidate queue tags only. The admin's queue list and badge still refresh, but there's no reconciliation of another user's item, no activeWorkflowQueueItemId replacement, and no node-state reset. That also fixes two things I hadn't noticed: an admin was getting an error toast for another user's failed item, and their $lastProgressEvent was cleared on any user's terminal status.

Single-user mode (no authenticated user) is unaffected.

The guard inside onInvocationComplete is now redundant but kept as defense-in-depth, since buildOnInvocationComplete is exported and reachable directly.

Tests — you were right that the old test bypassed the coordinator. The new ones in setEventListeners.test.ts drive the real listeners and the real coordinator through setEventListeners for an authenticated admin, emitting foreign started/progress/error/complete and a full queue-status event, asserting node execution states, canvas processing state, completed-invocation tracking, $lastProgressEvent, and the toast are all unmutated. I verified they're not vacuous by neutralizing the guard: all 7 fail without it, while the 2 positive controls (admin's own event, single-user mode) still pass.

That check was worth doing — my first cut of the invocation_started case passed even with the guard disabled, because I'd seeded the node state as IN_PROGRESS and getUpdatedNodeExecutionStateOnInvocationStarted() re-set it to the same value. Seeding PENDING (plus a test that a foreign event doesn't materialize a node the admin doesn't have) makes it actually catch the regression.

[JPPhoto]

It looks like there's a problem with an admin's events:

• invokeai/app/api/sockets.py:328: An admin's own invocation_complete event is delivered twice because admin sockets belong to both user:{user_id} and admin rooms, and lines 331-340 emit separately to each room. The same file explicitly documents at lines 398-406 that separate emits duplicate delivery for sockets belonging to both rooms. Although getUpdatedNodeExecutionStateOnInvocationComplete() suppresses the second node-state update, invokeai/frontend/web/src/services/events/onInvocationComplete.tsx:274 only logs the duplicate and continues into clearCanvasWorkflowIntegrationProcessing(), addImagesToGallery(), and $lastProgressEvent.set(null) at lines 285-291. addImagesToGallery() then increments cached board totals and board.image_count at lines 74-98 for both deliveries. This affects authenticated admins generating their own images and every single-user client, which is registered as both user:system and admin. The image-name insertion helper rejects the duplicate image name, but it does not prevent the independent board-count increments, leaving cached board counts inflated until a refetch. To expose this issue, add a test that routes an admin-owned InvocationCompleteEvent through _handle_queue_event, delivers every resulting socket payload through the frontend completion listener, and asserts that gallery insertion and board-count updates occur exactly once.

[lstein]

Closing in favor of #9358, which supersedes this PR.

#9358 carries this PR's work forward: the sanitized queue_items_retried companion and multi-owner _owner_and_admin_sids are included verbatim (tests too), and the listener-level filtering of other users' events is reimplemented via a single getEventScope classifier with the routing policy visible at each socket.on — which also addresses the legibility concern raised in review here.

One deliberate change from this PR's final state, agreed with @JPPhoto: a foreign invocation_complete is not dropped entirely. It downgrades to a single RTK tag invalidation (buildOnForeignInvocationComplete), so an admin actively viewing another user's board still sees new images appear (queue tab and gallery stay consistent), while idle clients do no work — no DTO fetches, no optimistic cache edits, no auto-switch, no progress clear.

Note: this PR's description predates the review rework and still describes the removed queue_counts_changed broadcast; #9358's description reflects the current design. #9358 also merges the two PRs' conflicting onInvocationComplete.test.ts files under the final semantics.