feat: report deposit poller liveness and bound the venue call - #111
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 18 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: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
Comment |
The deposit poller only emitted counters when it archived a row or hit an error, so a poller sitting on a quiet venue and one that had stopped polling altogether produced identical telemetry. Answering "is deposit capture still running" required correlating unrelated signals. Every poll now records cex_deposit_poller_polls_total, labelled by exchange and by outcome (ok, error, unsupported). It is recorded on every exit path, including an unexpected throw: the outcome starts as an error and is only narrowed once a poll actually completes, so a failure can never be reported as a healthy poll. The venue call is also bounded by a timeout (30s, below the 60s poll interval). fetchDeposits was previously unwrapped, so a request that never settled would strand the poll loop permanently with no log, no metric and no reschedule — the one failure mode that left no trace. A timeout now surfaces through the existing error path and the next poll is scheduled normally; it is never absorbed as a successful poll. The bound is a constant rather than an environment variable, matching the rest of the poller configuration.
3cc55d4 to
44f12e2
Compare
1 participant
Stacked on #110.
Problem
The deposit poller emitted a counter when it archived a row and a counter when it hit an error, and nothing otherwise. A poller sitting on a genuinely quiet venue and a poller that had stopped polling altogether produced identical telemetry, so "is deposit capture still alive?" could not be answered from the poller's own signals — it required correlating unrelated surfaces.
There was also one truly invisible death mode:
fetchDepositswas unwrapped. A request that never settled would strand the poll loop forever with no log, no metric, and no reschedule.Change
Per-poll heartbeat. Every poll now records
cex_deposit_poller_polls_total, labelled by exchange and by outcome (ok,error,unsupported). It is recorded on every exit path, including an unexpected throw — the outcome starts as an error and is only narrowed once a poll actually completes, so a failure can never be reported as a healthy poll. The outcome label is what separates alive and quiet from alive but failing; a bare counter would conflate them.Bounded venue call.
fetchDepositsis now wrapped in a 30s timeout, deliberately below the 60s poll interval. A timeout surfaces through the existing error path — error counter, warning log — and the next poll is scheduled normally. It is never absorbed into a silent success. The bound is a constant rather than an environment variable, matching the rest of the poller's configuration, which is intentionally env-free.Tests
Three added, none weakened or removed: heartbeat on a successful poll, heartbeat on an account whose venue does not support
fetchDeposits, and a never-settlingfetchDepositsrecorded asoutcome=errorwith the error counter, followed by a normal poll that archives.Full suite: 606 passing, 0 failing.
tscandbiomeclean.Release status
This is producer-side: merged is not released, and released is not deployed. The heartbeat only becomes visible in production telemetry after the cex-broker release chain runs — release PR and version tag, then the fiet-tee pin, then the fiet-maker submodule and root lockfile, then the SGX image build, then deploy.
Stack created with GitHub Stacks CLI • Give Feedback 💬