fix: throttle PROVIDERSTATUS server events - #2974
Conversation
setPluginStatus/setProviderStatus emitted the full provider status list on every call. A plugin calling it in a loop pushes megabytes per second into every admin-UI WebSocket; the socket buffers grow until the connection is cut and the Data Browser's own subscription data queues behind the backlog (SignalK#2972: 196 MB on one socket, ~2.4 MB/s). Coalesce calls into at most one PROVIDERSTATUS emit per second, trailing edge, so the admin UI still sees the latest status promptly while a chatty caller can no longer flood the socket. The 5-second periodic full refresh is unchanged.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan includes up to 2 reviews per rolling hour; 1 remains after this review. 📝 WalkthroughWalkthroughProvider-status events now pass through a throttling emitter. Burst updates are coalesced, status is refreshed every five seconds, immediate emissions remain available, and pending emissions are canceled during shutdown. ChangesProvider status event lifecycle
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to The change bounds PROVIDERSTATUS event delivery while preserving prompt updates and periodic refresh behavior; no actionable merge-blocking risk remains after normal checks and review. Sequence Diagram(s)sequenceDiagram
participant Server
participant ProviderStatusEmitter
participant PROVIDERSTATUS listeners
Server->>ProviderStatusEmitter: request() after provider-status update
ProviderStatusEmitter->>PROVIDERSTATUS listeners: emit coalesced status
Server->>ProviderStatusEmitter: emitNow() every five seconds
Server->>ProviderStatusEmitter: cancel() during shutdown
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
|
ready for human review |
|
|
||
| export const PROVIDER_STATUS_MIN_INTERVAL_MS = 1000 | ||
|
|
||
| export class ProviderStatusEmitter { |
There was a problem hiding this comment.
this is not a ProviderStatusEmitter - it does not emit provider statuses, but is used to emit them. to me it is ThrottledCaller - it calls the given function but throttles the calls as described. imho naming should reflect that and min interval come from callee.
2 participants
setPluginStatus/setProviderStatusemit aPROVIDERSTATUSserver event carrying the full provider status list on every call. A plugin that calls it in a loop turns that into a continuous stream on every admin-UI WebSocket — in #2972 ~2.4 MB/s, 196 MB queued on one socket before the overflow cut it — and everything else on that socket, including the Data Browser's own subscription data, waits behind the backlog.This coalesces status changes into at most one
PROVIDERSTATUSemit per second — the first change goes out immediately, further changes within the second fold into one emit when it expires — so a chatty caller is bounded at ~8 KB/s per client while the admin UI still shows the latest status within a second. The 5-second periodic full refresh is unchanged; a pending emit is cancelled onstop().Fixes #2972
Tested
npm run format,npm run build:all,npm test(server suite 1236 passing, workspaces green, ci-lint clean)test/providerStatusEmitter.ts: a burst of 1000 requests → one prompt emit and one more when the interval expires, prompt emit after a quiet interval,emitNowandcanceldrop a pending requestSummary
This PR throttles
PROVIDERSTATUSevents to one emission per second. The first status change emits immediately. Subsequent changes are coalesced into one trailing emission.The existing five-second full refresh remains unchanged. Pending emissions are canceled during
stop().ProviderStatusEmittercentralizes throttling behavior. Tests cover burst coalescing, delayed emissions,emitNow, and cancellation.This reduces WebSocket backlog from chatty plugins and improves Data Browser response time.