feat: support volatile emit, dropped only in the pre-connect window - #131
Conversation
|
Warning Review limit reached
Next review available in: 32 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
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 |
Implement ADR 0016: `.volatile` is a plain emit once the socket is connected, composing with rooms, broadcast, sender exclusion, and acks, and is dropped only when it is sent in the pre-connect window (0004), matching real socket.io's transport-not-writable drop. Add the `volatile` getter to the server and client socket contracts and the `io` / namespace broadcast path, and back it with a per-target drop gate in the existing send / BroadcastOperator path: a volatile emit to a socket whose client has not completed its connection is skipped, otherwise it delegates to the normal delivery. The gate keys on connection state rather than a simulated backpressure buffer, which a mock has no source for. The dual-run tests cover steady-state delivery in both directions, rooms, broadcast, and acks, plus the server-side pre-connect drop proven with the marker pattern. The client-side pre-connect window is not cleanly reachable through the shared harness, noted in the test file.
0aa515d to
339770b
Compare
1 participant
Summary
Adds
socket.volatile.emit(...)(andio.volatile.to(room),socket.volatile.broadcast) on both sides. Per the model measured and source-confirmed against real socket.io 4.8.3 (ADR 0016): a volatile emit is an ordinary emit once the connection is settled, and is dropped only in the pre-connect window. The gate is connection state, not simulated backpressure, because a mock has no transport buffer to overflow, so pass-through in steady state is the faithful behavior; the drop reproducestransport.writable === falseduring the handshake write.BroadcastOperatorgains a per-recipient volatile skip (a target whose client has not completed its connection is skipped), matching real socket.io deciding volatile per recipient. Rooms, sender exclusion, and ack all behave normally otherwise. The real side needed no changes.Scope note (documented in the test file)
The server-side pre-connect drop is cleanly observable and tested with the marker pattern on both targets. The client-side pre-connect window is not cleanly reachable through the shared harness: the only public route to a disconnected client is a reconnect, and real socket.io-client buffers a volatile emit across a reconnect (rather than dropping it), which is reconnection behavior and explicitly out of smocket's scope. That one test was removed and the reasoning recorded in
volatile.test.ts; the mock's client-side gate still drops when not connected per the model, and the divergence only surfaces in the out-of-scope reconnect case.Related issue
Closes #122
Checklist