Repository navigation
Start ring state polling after 9s instead of 15s - #1859
Conversation
Lowers RingStatePollingConfig.DEFAULT_START_AFTER_MS from 15s to 9s, so a caller whose coordinator websocket died silently learns the ring outcome sooner. In a 30s ring window reads land at 9/14/19/24/29s instead of 15/20/25s. Still overridable through startAfterMs. The startAfterMs KDoc claimed the delay was kept above the websocket ping interval; that is no longer true at 9s, so it now states the actual trade.
PR checklist ✅All required conditions are satisfied:
🎉 Great job! This PR is ready for review. |
SDK Size Comparison 📏
|
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (2)
Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review. WalkthroughThe default ring polling delay changes from 15 seconds to 9 seconds. Poller tests update their timing schedules and expected read counts to match. ChangesRing polling delay
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~8 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to The shorter delay is intended to recover sooner when the coordinator websocket dies silently, with a documented possibility of an extra read for slow answers. No unresolved merge risk is evident. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 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. A rabbit checks the ringing clock, Comment |
|
🚀 Available in v1.36.0 |



Goal
Closes AND-1607 — a caller whose coordinator websocket died silently waits 9s rather than 15s before the first
ring_stateread. Mirrors stream-video-js#2492.Implementation
RingStatePollingConfig.DEFAULT_START_AFTER_MS15s → 9s. In a 30s ring window reads land at 9/14/19/24/29s instead of 15/20/25s. Still overridable throughstartAfterMs.startAfterMsKDoc claimed the delay was kept well above the websocket ping interval so a merely slow answer would not poll. That stops being true at 9s — the health-check cycle is ~11s, and a callee taking ten seconds to answer now costs a read. It now states the trade it actually makes.RingStatePollerTestdrives virtual time off the default rather than a named constant, so its advances and expected read counts move with it.DEFAULT_START_AFTER_MSis apublic const val, so Kotlin inlines it: an integrator referencing the constant directly keeps15_000until they recompile. Callers taking the default pick it up on a version bump.Testing
Not re-verified on a device: the rescue path is untouched, only when the first read is issued.
Summary by CodeRabbit