fix: scope socket events and queue UI per user in multiuser mode

[lstein]

Summary

Supersedes #9314 and #9353, which fixed overlapping parts of the same problem: in multiuser mode, socket events for one user's generations leaked into other users' (especially admins') personal UI — hijacking the gallery's auto-switch, the progress bar, the favicon badge, and queue counts. This PR combines both fixes, resolves their conflicting handling of invocation_complete with the invalidate-only "middle ground" agreed with @JPPhoto, and restructures the frontend event handling so the per-user routing logic is explicit and readable (addressing @JPPhoto's review feedback on legibility).

It also fixes a bug found while smoke-testing this branch: bulk cancels (cancel_all_except_current / delete_all_except_current) emitted no events at all, so other clients' queue badges went stale when an admin canceled their items.

How multiuser event handling works after this PR

Backend: room-based routing (invokeai/app/api/sockets.py)

On connect (_handle_connect), each authenticated socket joins its personal room user:<user_id>; admin sockets additionally join admin. In single-user mode the lone client joins user:system and admin. Queue subscribers also join the queue room (default).

_handle_queue_event routes each queue event by type:

Event	Owner	Admins	Other users (queue room)
invocation_progress	full	—	—
invocation_started / complete / error	full	full	—
queue_item_status_changed, batch_enqueued	full	full	sanitized companion (user_id="redacted", identifiers/errors cleared)
queue_items_retried, queue_items_canceled (new)	full, scoped to own item ids	full	sanitized companion (no ids, no owners)
queue_cleared (user-scoped)	full	full	sanitized companion
queue_cleared (unscoped)	full broadcast to the whole queue room

Every owner+admin delivery is a single emit to [user room, admin] — python-socketio dedups recipients across a room list, so a socket in both rooms (an admin who owns the item, or the single-user client, which is always in both) receives exactly one copy instead of processing the event twice.

Sanitized companions exist so non-owners' queue lists and badge totals refetch without seeing whose items changed or what they were. _owner_and_admin_sids() computes the skip_sid list so owners and admins never receive a redacted second copy that would clobber their full-fidelity caches.

Progress events are owner-only because no admin UI consumes other users' progress — this is the primary guard against progress-bar hijacking; the frontend filter below is defense in depth.

Frontend: ownership decided at the listener

getEventScope(getState, data) (src/services/events/eventScope.ts) is the single classifier used everywhere. It returns:

• 'own' — the current user's event (in single-user mode there is no authenticated user, so every event is 'own' and behavior is identical to before);
• 'foreign' — another user's full event, which only admin clients ever receive (via the admin room);
• 'sanitized' — a redacted companion (user_id === "redacted").

It replaces the three near-duplicate predicates (isOwnEvent, isOwnItem, inline 'redacted' checks) that were previously scattered mid-handler.

Classification requires auth.user, so in multiuser mode useSocketIO defers the socket connection until it has hydrated from /me — see the review-fixes section below.

setEventListeners.tsx routes each event at the socket.on callback, before any state is touched, so downstream handlers only ever see events they should act on:

• invocation_started / invocation_progress / invocation_error: dropped unless 'own'. Foreign events must not reach the workflowExecutionCoordinator, node execution states, or $lastProgressEvent.
• invocation_complete: 'own' → the coordinator → buildOnInvocationComplete; otherwise → buildOnForeignInvocationComplete.
• queue_item_status_changed: 'own' → buildOnQueueItemStatusChanged; otherwise → buildOnNonOwnerQueueItemStatusChanged.
• queue_items_canceled (new): tag invalidation for queue caches, plus per-item tags when the event names ids.

Key handlers (each now free of per-user conditionals, since scope is decided upstream):

• buildOnInvocationComplete (onInvocationComplete.tsx) — own completions only: fetches result image DTOs, optimistically updates gallery caches (board totals, image name lists), auto-switches the gallery to the new image, clears the progress indicator.
• buildOnForeignInvocationComplete (same file) — the middle ground for admins observing other users. No DTO fetches, no optimistic cache edits, no auto-switch, no progress clear: it dispatches a single invalidateTags(FOREIGN_GALLERY_REFRESH_TAGS) (ImageNameList, BoardImagesTotal, board list, VirtualBoards). RTK Query only refetches invalidated queries with active subscribers, so an admin actively viewing another user's board stays fresh within one round-trip while idle admin clients do no work at all.
• buildOnQueueItemStatusChanged / buildOnNonOwnerQueueItemStatusChanged (onQueueItemStatusChanged.tsx, extracted from a ~120-line inline handler) — the own path does the optimistic queue cache updates, failure toast, and progress clear; the non-owner path (sanitized companion or admin-room copy) only invalidates queue tags.

Per-user queue counts. SessionQueueStatus gains user_pending / user_in_progress, populated for the requesting user. ProgressBar, the favicon badge (useSyncFaviconQueueStatus), and the invoke buttons use them via useUserHasActiveQueueItems, falling back to the global counts in single-user mode. The invoke buttons now spin while the user has queued sessions, so enqueueing gives feedback even when another user's generation occupies the processor. A full queue_item_status_changed event embeds the owner's fresh per-user counts, so the owner's personal UI updates from the event without waiting for a refetch; the sanitized companion nulls them, and withRetainedUserCounts (queueStatusEvents.ts) retains the last known values for statuses that carry none until the accompanying invalidation refetches them.

Bulk cancel notification (new). cancel_all_except_current and delete_all_except_current previously updated rows in one SQL statement and emitted nothing — only the initiating client (via its own mutation) refreshed. They now emit queue_items_canceled with the affected item ids grouped by owner, routed like queue_items_retried (see table above), so every client's badge and queue list update immediately.

Resolution of the #9314 / #9353 conflict

The two PRs disagreed on foreign invocation_complete: #9353 kept admins' gallery caches live via optimistic updates; #9314 (per review) ignored foreign events entirely, which left an admin's queue tab showing an item completed while the gallery beside it never showed the image. The middle ground adopted here — invalidate-only — gets the freshness of the former at nearly the simplicity of the latter, with no per-image fetches and no partial gating inside handlers.

Code-review fixes (ce65777, 274374c)

A review pass over the finished branch surfaced eight issues, fixed in ce65777:

• Socket connection now waits for auth hydration. The socket used to connect with the localStorage token as soon as the app mounted, before /me populated auth.user — so a reload during the user's own running generation misclassified their events as 'foreign' in that window, silently dropping one-shot side effects (progress, node execution states, gallery auto-switch, the failure toast) that never replay. useSocketIO now defers connect() until auth.user has hydrated whenever a token is present; the 'foreign' fallback in getEventScope remains as defense in depth.
• Single-emit delivery everywhere. queue_item_status_changed, batch_enqueued, and the generic queue-item fallback still used two separate emits (user room, then admin room), so a socket in both rooms received and processed every event twice — in single-user mode, that was every client on every status change. They now use the same single emit(room=[user_room, "admin"]) as the invocation events.
• useIsGenerationInProgress is now user-scoped, so the Dockview progress/canvas tabs no longer react to other users' generations.
• delete_by_destination no longer double-signals the current item: it is canceled with its own per-item status event, so it is excluded from the bulk queue_items_canceled event (still deleted and counted).
• The invoke-button spinner respects the full disabled state (queue.isDisabled || !canWriteImages), so it can no longer animate on a disabled button.
• Queue invalidation tags share one core (QUEUE_CHANGED_TAGS, spread by all five queue event handlers), preventing the hand-copied lists from drifting apart.
• Narrow invalidation for admin-room full events: the non-owner status-changed handler now uses id-scoped BatchStatus / QueueCountsByDestination tags when the event carries real ids, reserving type-level invalidation for the sanitized companion — so an admin client on a busy queue no longer refetches every batch/destination query on every foreign status change.

A second adversarial review pass over the updated branch (including the fixes above) confirmed the fixes held up and surfaced two more items, fixed in 274374c:

• In-tab logout/session expiry now tears the socket down. This gap is pre-existing (the socket was never disconnected on an SPA-navigation logout, keeping the old user's room membership — and private events — until the next login's full-page reload), but it belongs to the code this PR reworks. socketOptions is now derived from the redux auth token instead of a one-time localStorage read, making the token a dependency of the connect effect: logout re-runs it, disconnecting the old socket. This also removes the dual token source (redux vs. mount-time localStorage).
• Corrected a misleading comment on the own-path SessionQueueStatus invalidation: the per-user counts now arrive in the event's embedded queue_status; the refetch is kept because it refreshes .processor (which the optimistic write never touches) and reconciles event drift — the comment previously suggested it existed for the counts, inviting removal as "redundant".

Testing

• tests/app/test_invocation_event_socketio.py — backend routing for invocation events.
• tests/app/routers/test_multiuser_authorization.py — sanitized-companion routing for status changes, retries, cancels, and clears (full events stay private; companions carry no identifying data; owners/admins skipped; full events delivered in a single emit).
• tests/app/services/session_queue/test_session_queue_bulk_cancel_events.py — bulk cancel/delete emit queue_items_canceled grouped by owner (regression test for the stale-badge bug), and delete_by_destination excludes the separately-canceled current item.
• tests/app/services/session_queue/test_session_queue_status_user_scoping.py — per-user counts.
• Frontend: eventScope.test.ts, onInvocationComplete.test.ts (own path auto-switches; foreign path invalidates only, never fetches DTOs, never touches selection/progress), setEventListeners.test.ts (cross-user isolation: foreign events don't reach the coordinator/node states/progress; sanitized and foreign status changes are invalidate-only with id-scoped tags for admin full events; single-user mode unaffected), queueStatusEvents.test.ts.
• Manual two-user smoke test: badge counts per user, no gallery hijack, progress bar/favicon scoped, invoke-button spinner, admin bulk cancel updates other users' badges.

Follow-ups (out of scope)

• Centralize the hand-maintained sanitization field lists (the router's sanitize_queue_item_for_user plus the model_copy(update=...) companion blocks in sockets.py) into .sanitized() methods on the event models, so a newly added sensitive field cannot silently leak from a missed site.
• workflowExecutionCoordinator's per-item owner map is now mostly a guard (foreign events are filtered upstream); it could be simplified in a later PR — note the queue_cleared listener is deliberately not scope-filtered, which is what keeps the map load-bearing today.
• If admin clients watching very busy queues show refetch churn from the invalidate-only gallery refresh, a debounce can be layered on.

🤖 Generated with Claude Code