History read before the event skip-list is missing every event the old allowlist did not keep #23

New Issue

grenade · 2026-09-16T14:22:59Z

grenade commented

2026-09-16 14:22:59 +00:00

What was found

While checking #22's endpoint against mainnet, the mining address qzowWAgbzjc2XfHY4vyEo2eVLKbknTESUFoXnisQuUh1x1koo (first reward at block 13160) had no deposit below transfer_count 17,142, at block 18,511. indexed_from says 1.

/v1/chains/quantus/events/Wormhole/NativeTransferred?before=18510 is empty, while MiningRewards/MinerRewarded and Balances/Transfer below 18510 are present.
A mainnet node decodes Wormhole::NativeTransferred in blocks 18400 and 18509, under spec 152 (the same runtime as the blocks that are indexed). The chain has the events; the index does not.

Why

Until 1e8869e (2026-09-10 07:55 +0300, "index the whole event surface") the event interest list was an allowlist of two entries: ("MiningRewards", "*") and ("Balances", "Transfer"). Every block the backfill read before that deploy was claimed in event_scan with only those two kinds kept. The skip-list that replaced it only applies to blocks read afterwards, and event_scan never goes back over a range it has claimed.

The boundary on mainnet is block 18510, whose first surviving deposit is stamped 2026-09-10T05:03Z, the deploy. Planck and Heisenberg have the same hole over whatever they had read by then.

What is missing below it is not only wormhole transfers but every kind the allowlist didn't name. So account pages, the distribution table's flows and the wormhole summary are all quietly short for that history, and nothing on the site says so.

Fix

Re-read history under the current policy. record_events and record_extrinsics are upserts on their primary keys, so reading a block twice is idempotent. A migration that sets each chain's event_scan.low = high makes the backfill walk from the tip back to genesis again. indexed_from reports the true, shrinking gap while it does, rather than a claim of coverage the rows don't support.

A cursor that records what was read, not only where, would stop the next policy change from doing this again. That is a bigger change. For now, a note in CLAUDE.md's "things that cost an afternoon" says that changing SKIPPED_EVENTS needs a migration like this one.

## What was found While checking #22's endpoint against mainnet, the mining address `qzowWAgbzjc2XfHY4vyEo2eVLKbknTESUFoXnisQuUh1x1koo` (first reward at block 13160) had no deposit below `transfer_count` 17,142, at block 18,511. `indexed_from` says 1. - `/v1/chains/quantus/events/Wormhole/NativeTransferred?before=18510` is empty, while `MiningRewards/MinerRewarded` and `Balances/Transfer` below 18510 are present. - A mainnet node decodes `Wormhole::NativeTransferred` in blocks 18400 and 18509, under spec 152 (the same runtime as the blocks that are indexed). The chain has the events; the index does not. ## Why Until `1e8869e` (2026-09-10 07:55 +0300, "index the whole event surface") the event interest list was an allowlist of two entries: `("MiningRewards", "*")` and `("Balances", "Transfer")`. Every block the backfill read before that deploy was claimed in `event_scan` with only those two kinds kept. The skip-list that replaced it only applies to blocks read afterwards, and `event_scan` never goes back over a range it has claimed. The boundary on mainnet is block 18510, whose first surviving deposit is stamped 2026-09-10T05:03Z, the deploy. Planck and Heisenberg have the same hole over whatever they had read by then. What is missing below it is not only wormhole transfers but every kind the allowlist didn't name. So account pages, the distribution table's flows and the wormhole summary are all quietly short for that history, and nothing on the site says so. ## Fix Re-read history under the current policy. `record_events` and `record_extrinsics` are upserts on their primary keys, so reading a block twice is idempotent. A migration that sets each chain's `event_scan.low = high` makes the backfill walk from the tip back to genesis again. `indexed_from` reports the true, shrinking gap while it does, rather than a claim of coverage the rows don't support. A cursor that records *what* was read, not only *where*, would stop the next policy change from doing this again. That is a bigger change. For now, a note in CLAUDE.md's "things that cost an afternoon" says that changing `SKIPPED_EVENTS` needs a migration like this one.

grenade referenced this issue from a commit

2026-09-16 14:23:39 +00:00

fix(data): re-read event history under the current keep policy

grenade closed this issue

2026-09-16 15:11:30 +00:00

grenade referenced this issue from quantus/extension

2026-09-16 15:36:13 +00:00

Wallets: one secret, shown as every account it unlocks (ML-DSA-65, ML-DSA-87, wormhole) #14

Sign in to join this conversation.