[jackhai9]

Summary

The trading-data panel's five-minute history loop never converged. It expected every series to publish a row stamped with the boundary B, but live responses show two kinds of timestamps:

Series	Newest row in a period starting at B	Reaches it at
Open interest, top account ratio, top position ratio, global account ratio	B	about +43–195 s
Taker volume	B - 5m (labelled by the start of the period it covers)	about +163–203 s
Basis	B - 5m	before +64 s

These were checked with public BTCUSDT GETs on 2026-10-29 at +64, +203 and +293 s, and match the earlier review sample.

Because taker volume and basis never reached B, every period retried until it ended: about 12 attempts per period, in hidden tabs too. Each attempt rebuilt the whole panel, which also closed any open detail view. Opening a symbol mid-period additionally repeated the complete batch right after the initial one.

Changes (trading data 1.2.7; install URLs unchanged):

• Per-series completion: each series is complete at its own newest row (B, or B - 5m for taker volume and basis). Genuinely delayed rows still retry on the existing 10/15/20/30 s schedule within the period.
• No repeated batch: a complete batch requested after the five-second grace is not repeated within its period; only missing series retry. Activating before the grace still gets the regular full attempt at the grace.
• No idle rebuilds: a retry that returns unchanged rows and provenance updates the footer time but does not rebuild the panel.
• Fewer per-second allocations:
  • the footer clock and the funding note format only when their timestamp changes, so a system time-zone change still applies on the next update;
  • number formats are reused per precision;
  • funding status hidden/title are written only when they change.

Evidence

• New test/unit/binance-trading-data-history-refresh.test.js, using the live publication model, fails on the previous artifact:
  • 14 history requests where 7 are expected;
  • a full 7-endpoint batch where only open interest should retry.
  • With the change, a fully published period needs no further requests; a missing open-interest row retries alone; an unchanged retry keeps the same row nodes.
• Existing retry scenarios had modelled taker and basis rows at B - 5m as "delayed". They now use rows two periods back, so they still exercise real delays. The expired-period scenario no longer expects the duplicate batch after installation (funding history requests 3 → 2).

Testing

• npm run lint:tests: pass
• npm test: 2696/2696, 0 cancelled
• npm run test:ui: 628/628; the two data-panel specs: 43/43
• npm run check:binance-userscripts: pass
• Reproducible trading-data build; git diff --check passes

Not verified

• No live Binance page or Tampermonkey install was exercised.
• The publication timing was sampled on one symbol across one period today.
• The funding-interval metadata refresh cadence and per-symbol cache eviction are unchanged.

🤖 Generated with Claude Code