validation: Make ReplayBlocks interruptible #30155

1. 
   mzumsande commented at 3:12 pm on May 22, 2024: contributor

   This addresses the problem from #11600 that the Rolling Forward process after a crash (ReplayBlocks()) is uninterruptible. ReplayBlocks can take a long time to finish, and this can be especially annoying to GUI users who are taunted to “press q to shutdown” even though pressing “q” does nothing.

   Now, when an interrupt is received during ReplayBlocks(), the intermediate progress is saved: In addition to writing the updated coins to disk, the flush adjusts the lower head block (saved in DB_HEAD_BLOCKS), so that with the next restart, the replay continues from where it was stopped without losing progress.

   I tested this manually on signet: A situation where ReplayBlocks() becomes necessary can be created by syncing with -dbcrashratio=1 and stopping the node after ~70k blocks. Then, after the next restart, the replay process can be interrupted. I then used the dumptxoutset output to check that the final utxo-set hash is unaffected by how many times the process is interrupted.

2. 
   DrahtBot commented at 3:12 pm on May 22, 2024: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage

   For detailed information about the code coverage, see the test coverage report.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

   Conflicts

   Reviewers, this pull request conflicts with the following ones:

   • #30364 (logging: Replace LogError and LogWarning with LogAlert by ryanofsky)
   • #30342 (kernel, logging: Pass Logger instances to kernel objects by ryanofsky)

   If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

3. DrahtBot added the label Validation on May 22, 2024
4. validation: Make ReplayBlocks interruptible

   Now, when an interrupt is received during ReplayBlocks the
   intermediate progress is flushed:
   In addition to updating the coins on disk, this
   flush adjusts the head blocks, so that with the next
   restart, the replay continues from where we stopped.

   26e78f2ee4
5. in src/validation.cpp:4758 in 4bd626ec6e outdated

   4753@@ -4754,6 +4754,12 @@ bool Chainstate::ReplayBlocks()
   4754         LogPrintf("Rolling forward %s (%i)\n", pindex.GetBlockHash().ToString(), nHeight);
   4755         m_chainman.GetNotifications().progress(_("Replaying blocks…"), (int)((nHeight - nForkHeight) * 100.0 / (pindexNew->nHeight - nForkHeight)), false);
   4756         if (!RollforwardBlock(&pindex, cache)) return false;
   4757+        if (m_chainman.m_interrupt) {
   4758+            LogPrintf("Flushing intermediate state of replay\n");
   

   ---

   ---

   

   maflcko commented at 6:35 pm on May 22, 2024:

   0            LogInfo("Flushing intermediate state of replay\n");
   

   nit: For new code it would be better to use the non-deprecated non-confusing alias LogInfo over LogPrintf.

   ---

   

   mzumsande commented at 8:33 pm on May 22, 2024:

   sure - updated.
6. mzumsande force-pushed on May 22, 2024

Contributors
mzumsande DrahtBot maflcko luke-jr

Labels
Validation