I found a DUSK indexing trap that can leave an off-chain database believing something happened even when the transaction rolled it back.
After Boreas, a reverted contract event does not simply disappear. Rusk keeps it in archive history, but marks it as reverted. At the same time, that event is removed from the canonical block bloom, and a reverted staking event is not allowed to change the provisioner set.
So if I build an indexer that treats “event exists” as “state changed,” I can manufacture phantom activity from perfectly valid chain data. A failed contract call can still leave an event record behind, while the canonical state correctly says nothing happened.
That means recovery logic matters as much as live ingestion. If my service restarts and backfills from archive history, it has to apply the reverted marker before rebuilding balances, positions, or stake-related views. Otherwise the restart itself can create a mismatch that was not there before.
I would test DUSK indexers by replaying successful and reverted events through the same pipeline and demanding the same final state as Rusk.
An event record is evidence that execution reached a point. It is not proof that the state survived.
#dusk $DUSK @Dusk
After Boreas, a reverted contract event does not simply disappear. Rusk keeps it in archive history, but marks it as reverted. At the same time, that event is removed from the canonical block bloom, and a reverted staking event is not allowed to change the provisioner set.
So if I build an indexer that treats “event exists” as “state changed,” I can manufacture phantom activity from perfectly valid chain data. A failed contract call can still leave an event record behind, while the canonical state correctly says nothing happened.
That means recovery logic matters as much as live ingestion. If my service restarts and backfills from archive history, it has to apply the reverted marker before rebuilding balances, positions, or stake-related views. Otherwise the restart itself can create a mismatch that was not there before.
I would test DUSK indexers by replaying successful and reverted events through the same pipeline and demanding the same final state as Rusk.
An event record is evidence that execution reached a point. It is not proof that the state survived.
#dusk $DUSK @Dusk
