fargate-spot-interruption-breaking-all-socket-connections
Symptom
Task stopped with “Your Spot Task was interrupted.” All connected users lost their socket sessions simultaneously.
Root cause
Fargate Spot capacity reclaimed by AWS. No graceful connection migration was in place for long-lived WebSocket connections.
Fix
Switched production to standard Fargate. Spot retained only for dev/staging where connection drops are acceptable.
cross-tenant-duplicate-key-errors-on-fresh-local-database
Symptom
Creating a second account locally threw duplicate key errors on ChannelMember.
Root cause
The ChannelMember model was missing tenantId in its schema field definition. The tenantIsolationPlugin tried to inject it pre-validate, but Mongoose strict mode stripped unknown fields, so docs saved without tenantId. The global unique index on channelId + userId then correctly rejected the second doc.
Fix
Added tenantId explicitly to the ChannelMember schema. Added migration_001b_drop_old_tenant_indexes to prevent recurrence after local database prunes.
hasSentAuth.current-flag-surviving-iframe-remounts
Symptom
After an auth timeout and page remount, EMBED_READY fired but WNP skipped sending credentials because hasSentAuth.current was still true.
Root cause
The flag was set on first auth attempt. The cleanup function didn’t reset it on unmount, so it persisted across React remounts of the component.
Fix
Reset hasSentAuth.current = false both in handleLoad (on iframe reload) and in the useEffect cleanup function.
deletedAt-$unset-prematurely-removing-message-filter-boundary
Symptom
When User B sent a new message to User A (who had deleted the conversation), all previous messages reappeared, not just messages after the deletion.
Root cause
restoreForParticipants was incorrectly calling $unset deletedAt, which is only supposed to happen in restoreForUser. Without the timestamp, the visibleAfter filter had no boundary to apply.
Fix
$unset deletedAt moved exclusively to restoreForUser. restoreForParticipants only removes the user from deletedBy array. Restore call moved to after message creation so the new message triggers the restore.
cors-failure-on-sso-init-from-iframe
Symptom
POST /tenants/sso/init from the iframe returned a CORS error.
Root cause
The backend’s CORS_ORIGIN was a static environment variable. The iframe’s request origin didn’t match the hardcoded value.
Fix
Corrected allowed origin in env (immediate fix). Identified architectural gap: dynamic per-tenant CORS validation via database-driven allowedOrigins lookup is the permanent fix, still pending.
tenant-filter-plugin-missing-findbyid-from-scoped-method-list
Symptom
No error, no report: caught during review of the multi-tenant rollout diffs, not by a failing test or a user.
Root cause
The Mongoose tenant-filter plugin auto-injected tenantId scoping into most query methods, but findById wasn’t on the list. Any Model.findById(...) call anywhere in the codebase bypassed tenant isolation entirely, a real cross-tenant data leak live for about a week between the rollout and the fix.
Fix
Added findById to the plugin’s auto-scoped method list. Same rollout also fixed an AsyncLocalStorage ordering bug where the tenant-context middleware called next() after its .run() callback had already returned, so downstream handlers executed with no tenant context active at all.
presence-manager-tenantid-bound-to-singleton-constructor
Symptom
PresenceManager took tenantId as a constructor parameter for one day, then it was reversed.
Root cause
PresenceManager is instantiated once as a process-wide singleton in server.ts, not one instance per tenant. Binding tenantId at construction time was structurally incompatible with that pattern from the moment it was added.
Fix
Tenant now passed as an explicit parameter on every method call (processHeartbeat(userId, tenantId, ...)), with Redis keys built per-call as presence:${tenantId}:${userId}. The reversal was incomplete, though: the class still declares private tenantId, never assigned, and two call sites in processHeartbeat’s “already online, status changed” branch still reference this.tenantId instead of the local parameter, a narrow, still-live bug limited to that one branch.
postmessage-init-chat-race-condition-on-iframe-mount
Symptom
Users would intermittently see “Authentication timeout” on the embedded chat: the auth handshake never completed.
Root cause
Not CORS or cookies, despite that being the first assumption. The original flow had the parent send an INIT_CHAT message via postMessage, with the iframe exchanging it via a REST call. The iframe’s postMessage listener wasn’t guaranteed to be mounted before the parent sent the init message, a cross-frame mount-timing race, not a security restriction.
Fix
Replaced the postMessage handoff entirely with the token-in-URL-query-param approach (arch-03): SSO token and signature authenticated over the Socket.IO handshake itself, so auth rides on an already-established connection instead of assuming listener readiness. postMessage is still used today for CHAT_REAUTH and presence events, just not the initial handoff.
