bountx / LOB / 22869120259

88%

push

github

feat: Implement watchdog mechanism for Binance and Kraken adapters to… (#31)

* feat: Implement watchdog mechanism for Binance and Kraken adapters to detect stale feeds and force reconnects

* test: Add feed data age sentinel tests for lastUpdateTimeMs

Tests verify the 0-sentinel pattern critical to the watchdog's
reconnect logic:
- DataAgeAbsentWhenSentinelIsZero: metric suppressed during startup/reconnect
- DataAgeEmittedAfterFirstUpdate: metric appears once book is live
- DataAgeValueApproximatelyCorrect: emitted value reflects elapsed seconds
- DataAgeSkipsZeroSentinelSymbolsInMultiSymbol: partial-data case
- DataAgeHeadersPresentWhenDataExists: HELP/TYPE headers present

* fix: Correct watchdog reconnect and clock consistency

Three fixes verified against current code:

1. Watchdog reconnect: webSocket.stop() alone does not trigger
   ixwebsocket auto-reconnect — add webSocket.start() immediately
   after stop() in both BinanceAdapter and KrakenAdapter watchdogs
   so the Open handler fires and re-enters the reconnect cycle.

2. Kraken watchdog placement: move watchdogThread_ creation to after
   both the connection wait and snapshot wait succeed in start().
   On any failure path webSocket_.stop() is called but no watchdog
   thread exists yet, eliminating the leaked-thread window.

3. steady_clock for lastUpdateTimeMs: staleness detection requires a
   monotonic clock; system_clock can jump backward on NTP adjustment
   and false-trigger a 2 s watchdog. Switch all lastUpdateTimeMs
   producers (handleWsMessage, handleBookSnapshot, handleBookUpdate)
   and consumers (runWatchdog x2, prometheus_format scrapeNowMs) to
   steady_clock. lastEventLagMs correctly stays on system_clock as it
   is compared against exchange-provided wall-clock timestamps.

* test: Fix data age tests to use steady_clock for lastUpdateTimeMs

The previous commit switched lastUpdateTimeMs to steady_clock; tests
were still using system_clock to populate the field, causing ... (continued)

14 of 14 new or added lines in 1 file covered. (100.0%)

389 of 466 relevant lines covered (83.48%)

35.2 hits per line