聊天记录
共 2 条，显示第 1-2 条
Thanks for checking! The weekly timing does fit — but in these windows the chain doesn't actually pause; trades keep happening, they're just missing from the exported archive. Two clear signs:
1. The fills are retrievable from the live API right now, timestamped inside the "gap". A chain pause would have none.
2. The archive contradicts itself — it contains post-gap fills whose startPosition requires earlier fills that are absent from the same archive.
Reproducible example (userFillsByTime, wallet 0x2e21358ecf609d76867ff3c6d2edc3b6cb26c098, coin FARTCOIN, 2025-06-21):
In the S3 archive, FARTCOIN jumps from a fill at 09:16:14 (startPos 459.8, buy 21 → position 480.8) straight to the next at 09:31:24 (startPos 426.8). 480.8 ≠ 426.8 with no fill in between — the archive can't explain its own position.
The live API fills that gap with 6 trades the archive lacks: 09:22:05 (startPos 480.8, oid 104594473517), 09:23:02, 09:24:45, 09:27:48, 09:28:24, 09:30:21 — each chains perfectly back to the 09:31:24 fill (480.8 → … → 426.8). Their oids increase monotonically across the window, so orders were being sequenced the whole time. Across all wallets, ~530 fills are missing from the archive in just this one window.
So it looks like the archival/export node restarts and resumes at the live tip without backfilling, while the chain + API keep running — the gap is in the export, not the chain. Any chance those block ranges could be re-exported from a full archival node? Happy to share more windows.
Thanks for checking! The weekly timing does fit — but in these windows the chain doesn't actually pause; trades keep happening, they're just missing from the exported archive. Two clear signs:
1. The fills are retrievable from the live API right now, timestamped inside the "gap". A chain pause would have none.
2. The archive contradicts itself — it contains post-gap fills whose startPosition requires earlier fills that are absent from the same archive.
Reproducible example (userFillsByTime, wallet 0x2e21358ecf609d76867ff3c6d2edc3b6cb26c098, coin FARTCOIN, 2025-06-21):
In the S3 archive, FARTCOIN jumps from a fill at 09:16:14 (startPos 459.8, buy 21 → position 480.8) straight to the next at 09:31:24 (startPos 426.8). 480.8 ≠ 426.8 with no fill in between — the archive can't explain its own position.
The live API fills that gap with 6 trades the archive lacks: 09:22:05 (startPos 480.8, oid 104594473517), 09:23:02, 09:24:45, 09:27:48, 09:28:24, 09:30:21 — each chains perfectly back to the 09:31:24 fill (480.8 → … → 426.8). Their oids increase monotonically across the window, so orders were being sequenced the whole time. Across all wallets, ~530 fills are missing from the archive in just this one window.
So it looks like the archival/export node restarts and resumes at the live tip without backfilling, while the chain + API keep running — the gap is in the export, not the chain. Any chance those block ranges could be re-exported from a full archival node? Happy to share more windows.
**Gaps in the public hl-mainnet-node-data archive — fills missing after node restarts**
Hi HL team — flagging a data-quality issue in the public historical archive (the hl-mainnet-node-data bucket: node_fills / fills_by_block and replica_cmds). There are systematic gaps where fills are missing from the published data itself, not my pipeline — the trades clearly happened on-chain.
Pattern: when the archival node restarts, it resumes at the live chain tip without backfilling the blocks it missed. So there's a short window (minutes) with no exported fills, even though the chain kept producing blocks. Both node_fills/fills_by_block AND replica_cmds share the identical gap (same node), so it can't be recovered from either — only from a full archival node / the live API (limited retention).
Example (UTC): on 2025-06-21, node_fills has no fills between 09:17:07 and 09:31:14 (~846s); the order id advanced ~439,000 across the gap, so the chain was live. In replica_cmds the pre-restart session ends with a truncated 31 MB stub (file 636550000.lz4, last block 09:17:07) and the next session resumes at 636553440.lz4 (09:31:14) — blocks ~636551021–636553439 are in no session. Same pattern on 2025-06-28 (03:38:56–03:43:58) and 2025-09-27 (block gap 744216993 to 744217001). These recur ~weekly, clustered 07–11 UTC.
Questions: is this a known export limitation? Could the affected block ranges be re-exported / backfilled from a full archival node? If not, is there a recommended source for these historical fills? Happy to share the full list of windows. Thanks!
**Gaps in the public hl-mainnet-node-data archive — fills missing after node restarts**
Hi HL team — flagging a data-quality issue in the public historical archive (the hl-mainnet-node-data bucket: node_fills / fills_by_block and replica_cmds). There are systematic gaps where fills are missing from the published data itself, not my pipeline — the trades clearly happened on-chain.
Pattern: when the archival node restarts, it resumes at the live chain tip without backfilling the blocks it missed. So there's a short window (minutes) with no exported fills, even though the chain kept producing blocks. Both node_fills/fills_by_block AND replica_cmds share the identical gap (same node), so it can't be recovered from either — only from a full archival node / the live API (limited retention).
Example (UTC): on 2025-06-21, node_fills has no fills between 09:17:07 and 09:31:14 (~846s); the order id advanced ~439,000 across the gap, so the chain was live. In replica_cmds the pre-restart session ends with a truncated 31 MB stub (file 636550000.lz4, last block 09:17:07) and the next session resumes at 636553440.lz4 (09:31:14) — blocks ~636551021–636553439 are in no session. Same pattern on 2025-06-28 (03:38:56–03:43:58) and 2025-09-27 (block gap 744216993 to 744217001). These recur ~weekly, clustered 07–11 UTC.
Questions: is this a known export limitation? Could the affected block ranges be re-exported / backfilled from a full archival node? If not, is there a recommended source for these historical fills? Happy to share the full list of windows. Thanks!
Hyperliquid