Race condition: stale shoot events applied after namespace switch

[petersutter]

Description

When a user switches shoot namespaces while a socket event synchronization is in-flight, the stale response from the old namespace can be applied to the current state.shoots, causing shoots from the previous namespace to appear in the new namespace view.

Root Cause

The socket event handler (useSocketEventHandler) calls socketStore.synchronize(pluralName, uids) which is an async operation with up to 60s timeout. During this await, the user can switch namespaces (triggering shootStore.subscribe() with new context). When the old synchronize resolves, it patches the store without verifying the subscription context still matches.

Key factors:

• The shoot store does not expose isInitial, so the generic initialization guard from fix(socket): guard against missing operator during store patch #2962 does not protect it
• synchronizeLock only prevents concurrent sync for the same subscription options, not cross-namespace staleness
• The subscribe/unsubscribe flow has a gap where queued events from the old namespace can still be processed

Impact

• Stale shoots from namespace A appear in namespace B's list view
• Self-heals on next sync/reconnect, but confusing UX in the meantime
• More likely on slow connections or large namespaces where synchronize takes longer

Possible Approaches

• Context-check after await (compare subscription before/after synchronize)
• AbortController / signal to cancel in-flight synchronize when subscription changes
• Hybrid: signal aborts network, context-check as safety net

Related

• fix(socket): guard against missing operator during store patch #2962 — fixes uninitialized list store race (different bug category: initialization-scoped, not subscription-scoped)