Hello @Dhan team,
We run an automated market-data capture on your APIs and have been consistently well served by
the platform — the 20-depth feed in particular has been reliable enough that we built our
order-flow analytics directly on top of it. That is exactly why we would like your help
understanding a two-hour window on Monday 17 August 2026 where one instrument’s order book
came through wrong.
We have already done a full root-cause analysis on our side and satisfied ourselves that our
decoder is behaving correctly. We are not asking you to debug our code — we are asking whether
you can see what happened on the serving side, because the evidence points there and we cannot
see past your boundary.
What we observed
Instrument: NIFTY current-month future, NSE F&O — securityId 58072
Feed: 20-level market depth (twentydepth / DEPTH_20 websocket)
Window: 2026-08-17, 06:44:07 UTC → 09:01:26 UTC (11:44:07 – 14:31:26 IST)
Through that window every depth packet for this security arrived with a healthy BID half and a
frozen, implausible ASK half. Specifically:
-
The ASK array was byte-identical across 35,439 consecutive depth events spanning 2h15m —
zero change in any price, quantity or order count. -
Over the same period the BID half of the same security tracked the market normally, with a
repeat rate of 0.13 (i.e. ordinary). -
The frozen ASK ladder contained negative prices — best ask around −97.5, stepping in
10-point increments up to about +21 — with uniform 20-lot quantities (1300 = 20 × 65, one lot
= 65) andorders = 1on every level.
A negative price is not possible on an NSE F&O outright book. The values are well-formed IEEE-754
doubles at the correct byte offsets, so this is not a decode misalignment on our side — it reads
as a valid ladder belonging to some other book (its shape resembles a calendar-spread or
quote-machine ladder), delivered under securityId 58072.
Why we believe this was server-side
Four independent checks, all from our recorded session:
-
Our decode is correct. We read the documented 12-byte header plus 20 × [float64 price,
uint32 quantity, uint32 orders]. A wrong offset or width produces denormal garbage, not a tidy
ladder with exact lot multiples. The −97.5 is a legitimate float64 (0xC058600000000000) at
the correct offset of its level slot. -
Frozen, not evolving. One snapshot repeated 35,439 times is not a market. A live book does
not hold every level constant for two hours while its opposite side moves.
-
It healed on your side, with zero action from us. At 08:59:20 UTC securityId 58072 and
eight option contracts (strikes 24050, 24150, 24500, 24600 — CE and PE) went silent together
for approximately two minutes, while roughly sixteen other option books on the same
websocket connection kept flowing normally. At 09:01:26 UTC they resumed, and the ASK
half for 58072 was immediately correct and live (first healthy row: asks 24408 / 24408.1
against a bid of 24402).Our client logged no disconnect and no reconnect for the entire session — we never cycled
the socket and never re-subscribed. The correlated silence-then-heal across exactly that group
of instruments, on a connection that itself never dropped, is what makes us think a serving
partition carrying those nine instruments stalled and restarted. -
The fault was surgical. Measuring “identical consecutive value” ratios before the stall:
securityId 58072’s ASK side was 1.00 (2,782 of 2,782 identical), its BID side 0.13, and all
24 option books were 0.01–0.06 on both sides. Only one side of one instrument was affected.
The same setup was perfectly healthy the next day
We ran an identical capture on Tuesday 18 August 2026, 04:07–09:17 UTC — same client build,
same subscription, same securityId 58072. The future’s book was valid on all 309 of our
one-minute checkpoints, with normal spreads (e.g. bid 24280.1 / ask 24285.1). No frozen half, no
negative prices, not once.
We mention this because it rules out a persistent client-side problem and suggests a transient
serving-side condition on 17 August. It also means we cannot reproduce it on demand, which is
why your logs matter more than ours here.
What we would like from you
-
Can you confirm the incident from your side? securityId 58072, 20-depth feed, 06:44–09:01
UTC on 2026-08-17 — and the ~2-minute gap at 08:59:20–09:01:26 UTC across that group of nine
instruments. -
What caused the ASK half to freeze and to carry another book’s ladder? Understanding
whether this was a shard/partition fault, a cache issue, or a publisher stall tells us what to
monitor. -
The practically important one: would a client-side re-subscribe have healed it sooner?
We deliberately did not resubscribe, and we do not want to build an automatic reconnect loop
that thrashes the single depth socket carrying all our rails if it would not have helped. Your
answer decides whether we build that safeguard at all. -
Is there a recommended way to detect this class of fault early? A frozen half with
positive prices would have passed every plausibility check we had at the time. We have since
added a frozen-half detector, but if you expose a sequence number, publisher heartbeat or
staleness indicator per side that we are not yet using, we would rather use yours.
Impact, briefly
That instrument’s order book is the input to our entire order-flow layer, so for those 2h15m the
capture recorded a session we cannot analyse. We record composed books rather than raw halves, so
the window is not repairable after the fact — one trading day’s data lost for that instrument.
We would simply like to understand it well enough to know whether it can happen again on a day that matters more, and to
detect it in minutes rather than hours if it does.
Happy to provide the raw packet capture for that window, our decoder’s reading of the affected
packets, or a narrower time slice — whatever is most useful to your team. Thank you for taking a
look.
Best regards,
Arsh Panghal