fix(nonce): recompute evolving nonce on block count mismatch#102
fix(nonce): recompute evolving nonce on block count mismatch#102
Conversation
…cFromDB InsertBlockBatch (CopyFrom) writes blocks atomically but ProcessBatch runs separately. An OOM between the two leaves blocks in the DB with a stale epoch_nonces.block_count. On restart, ResyncFromDB read the stale count and if the reconnect overlap landed in a later epoch, the incomplete epoch's nonce was persisted uncorrected. ResyncFromDB now cross-checks block_count against the actual block count and recomputes the evolving nonce inline from raw VRF outputs on mismatch.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis pull request adds detection and recovery logic for block count mismatches in the nonce synchronization process. When a mismatch occurs between stored block count and actual blocks in the database, the evolving nonce is recomputed from raw VRF outputs and state is repaired. Changes
Sequence DiagramsequenceDiagram
participant NT as NonceTracker
participant DB as Database
participant VO as VRF Outputs
NT->>DB: ResyncFromDB (post-bulk insert)
DB->>DB: Count blocks for epoch
DB->>NT: Return actual block count
NT->>NT: Compare stored vs actual block_count
alt Block count mismatch detected
NT->>DB: Fetch previous epoch evolving nonce
DB->>NT: Return previous nonce (or initial)
NT->>VO: GetVrfOutputsForEpoch(current epoch)
VO->>NT: Return VRF outputs list
NT->>NT: Iterate VRF outputs to evolve nonce
NT->>DB: Upsert recomputed nonce + correct block_count
DB->>NT: Persist complete
NT->>NT: Update evolvingNonce & blockCount in-memory
NT->>NT: Log recomputation event
else Block count matches
NT->>NT: No action (nonce is valid)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Possibly related PRs
Poem
✨ Finishing Touches
🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
ResyncFromDBnow cross-checksepoch_nonces.block_countagainst actualCOUNT(*) FROM blocksRoot cause
InsertBlockBatch(CopyFrom) writes blocks atomically, butProcessBatch(nonce evolution) runs after as a separate step. An OOM between the two leaves blocks in the DB butepoch_nonces.block_countstale. On restart,ResyncFromDBread the stale count uncorrected.Test plan
TestResyncFromDB_BlockCountMismatch— simulates OOM scenario, verifies recomputeSummary by CodeRabbit
Bug Fixes
Tests