BUG-11 (Medium) — a room purge still running after the DELETE route's
~10s poll window was simply forgotten: no persisted state, no
follow-up, so Synapse finishing the purge moments later left the local
chat_rooms mapping (and audit trail) permanently stale. New table
pending_room_deletions (migration 0005, deliberately no FKs — must
outlive the org/team/chat_rooms row it references) plus a background
worker (processPendingRoomDeletions(), 30s tick) that keeps polling
delete_status and runs the same finalize step the route itself would
have: drop the mapping, write the audit entry. Capped at 30 attempts
(~15min) before giving up with a server-log error.
Verified end-to-end on talkhub/matrix: manually queued a pending
deletion row, confirmed it was cleared and audited
(finalizedByWorker: true) after one worker cycle. Also reconfirmed the
normal fast path (small room, completes within the poll window) still
returns 200 in ~1.2s.
BUG-12 (Low) — the 202/pending response used to be shoved into the same
`deleteError` state as real failures, rendering as a destructive alert
with the dialog stuck open and the delete button still enabled (inviting
a duplicate purge on a second click). Now a separate, neutral
`pendingInfo` banner; the dialog closes immediately since there's
nothing more to confirm.
Not addressed here: BUG-7/8/9/10 (never picked up since the first QA
round — flagging as a process gap, not just a code one), BUG-13 (no
system-wide audit log view exists yet to surface organization_id=null
entries — backlog item, out of this feature's scope), BUG-14 (no
client-side timeout on the DELETE request).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0143yYvjesjHndBACoweyK67
patrickandClaude Sonnet 5
3bc2ac8ef4