Heap-based expiry for unauthorized cooldown and IndexedDB rapid user-switch race.

[santhoshh-kumar]

realtime/src/server.ts — Heap-based expiry for unauthorized cooldown:

Previously, cleanupExpiredUnauthorizedCooldown did a full scan of the entire unauthorizedAccessCooldown map on every run. This was O(n) even if nothing had expired.

The new code maintains a min-heap (unauthorizedCooldownExpirations) sorted by denyUntil. Cleanup now peeks at the heap root and stops immediately if the earliest expiry hasn't passed yet — skipping the full scan. The heap processes at most 512 entries per cleanup run to avoid blocking.

The subtle correctness issue it handles: when a cooldown is renewed (same key, new denyUntil), a second entry is pushed onto the heap rather than updating the existing one. The stale entry from before the renewal will eventually surface during cleanup. The check existingState.denyUntil !== expiredEntry.denyUntil detects and skips those stale entries, preventing a renewed cooldown from being incorrectly evicted.

maybeRebuildUnauthorizedCooldownExpirationHeap handles heap bloat from accumulated stale entries by doing a full rebuild from the source-of-truth map when the heap is more than 4× the map size (and above 1024 entries).

web/services/indexed-db.service.ts — Fix race condition in user switches:

Previously, switching users rapidly could cause a race: setUserId only closed the DB if no close was already in progress (!this.dbClosingPromise). Rapid switches (A → B → C → B) would skip closure steps, and a subsequent getDB call might await a stale dbClosingPromise and then open the wrong database.

The fix replaces the single dbClosingPromise with a chained promise (dbSwitchPromise). Each call to setUserId appends a closeCurrentConnection step onto the chain — so no switch is ever skipped, they're always serialized. awaitStableUserSwitch loops until the promise reference stabilises, handling the case where another switch was queued while you were awaiting.

[gemini-code-assist]

Code Review

This pull request introduces a min-heap to optimize the cleanup of expired unauthorized access cooldowns in the realtime server and refactors the IndexedDB service in the web client to safely handle rapid user switches. Feedback indicates that triggering heap rebuilds during the connection handshake could introduce latency spikes and potential DoS vulnerabilities; it is recommended to move this logic to the background cleanup process.

[santhoshh-kumar]

The DoS argument from above comments doesn't seem to hold up but the suggestion to remove the calls is still correct because they're redundant!