feat: delete Room — purge transfers + kick participants (#92) - #94
Conversation
|
Warning Review limit reached
Next review available in: 24 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (18)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai full review |
✅ Action performedFull review finished. Your plan includes PR reviews subject to rate limits. More reviews will be available in 27 minutes. |
Review follow-up on #94. - closeRoom refuses to emit on a disconnected/lost socket (the emit would buffer and its ack never fire, spinning the delete button forever) and backstops the ack with a timeout - join distinguishes a deliberately-closed Room (RoomClosedError) from a lapsed one, mapped to NOT_FOUND like the others - tests: closeRoom fails fast when disconnected; the initiating Sender stays connected after close; join rejects a CLOSED Room
Review follow-up on #94. - closeRoom refuses to emit on a disconnected/lost socket (the emit would buffer and its ack never fire, spinning the delete button forever) and backstops the ack with a timeout - join distinguishes a deliberately-closed Room (RoomClosedError) from a lapsed one, mapped to NOT_FOUND like the others - tests: closeRoom fails fast when disconnected; the initiating Sender stays connected after close; join rejects a CLOSED Room
938bc09 to
f28bd68
Compare
Review follow-up on #94. - closeRoom refuses to emit on a disconnected/lost socket (the emit would buffer and its ack never fire, spinning the delete button forever) and backstops the ack with a timeout - join distinguishes a deliberately-closed Room (RoomClosedError) from a lapsed one, mapped to NOT_FOUND like the others - tests: closeRoom fails fast when disconnected; the initiating Sender stays connected after close; join rejects a CLOSED Room
f28bd68 to
634fad4
Compare
The Sender had no way to end a Room; it only died lazily at expiry. Adds a Sender-only teardown that removes everything and evicts everyone. - room:close socket message, guarded to the Sender's connection; the gateway purges the Room, notifies with room:closed, then disconnects the rest - RoomService.close flips the Room to CLOSED (already non-joinable via isExpired) after purging; purge logic is shared with the expiry sweeper - purge cascades objects + Transfer/FilePayload/TextPayload/Delivery rows - FE: Sender gets a destructive Delete Room control with an inline confirm, then navigates home; a kicked Receiver lands on a Room closed notice
Review follow-up on #94. - closeRoom refuses to emit on a disconnected/lost socket (the emit would buffer and its ack never fire, spinning the delete button forever) and backstops the ack with a timeout - join distinguishes a deliberately-closed Room (RoomClosedError) from a lapsed one, mapped to NOT_FOUND like the others - tests: closeRoom fails fast when disconnected; the initiating Sender stays connected after close; join rejects a CLOSED Room
634fad4 to
80f2b52
Compare
1 participant
What
The Sender had no way to end a Room on demand — Rooms only died lazily at expiry via the sweeper. This adds a Sender-only teardown that purges everything and evicts every Participant.
Changes
room:closemessage, authorised off the Sender's own connection (same auth boundary assendText). The gateway purges the Room, broadcastsroom:closed, then disconnects every other socket — the initiator stays connected long enough to get the ack and navigates away itself.deleteByRoomIdout ofExpirySweeperService.expireRoomintoRoomService.purgeRoomContents; both on-demand close and the sweeper use the exact same path.RoomService.closeflips the Room toCLOSEDafter purging.CLOSEDis already non-joinable viaisExpired, sojoinrejects it for free.Transfer/FilePayload/TextPayload/Deliveryrows.Tests
closepurges objects + rows and flips toCLOSED; a storage failure leaves the RoomACTIVE.closeRoomemits + resolves the ack;room:closedlatches closed; Sender delete flow emitsroom:closeonly after confirm; Receiver sees the closed notice; Receiver has no delete control.Depends on
Stacked on #93 (Text/Link persistence) — the purge cascade needs the
TextPayloadtable. Based on that branch; will retarget tomainonce #93 merges.Closes #92