DRAFT: Track the last rotation of online delete more accurately

[ximinez]

WIP. Follow-up to #5531.

High Level Overview of Change

Context of Change

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that only restructures code)
• Performance (increase or change in throughput and/or latency)
• Tests (you added tests for code that already exists, or your new feature included in this PR)
• Documentation update
• Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
• Release

API Impact

• Public API: New feature (new methods and/or new fields)
• Public API: Breaking change (in general, breaking changes should only impact the next api_version)
• libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
• Peer protocol change (must be backward compatible or bump the peer protocol version)

This PR may resolve #4883 and #3912.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (ximinez/online-delete-gaps@f456a85). Learn more about missing BASE report.

Additional details and impacted files

@@                     Coverage Diff                      @@
##             ximinez/online-delete-gaps   #5542   +/-   ##
============================================================
  Coverage                              ?   78.9%           
============================================================
  Files                                 ?     816           
  Lines                                 ?   72109           
  Branches                              ?    8404           
============================================================
  Hits                                  ?   56909           
  Misses                                ?   15200           
  Partials                              ?       0           

Files with missing lines	Coverage Δ
src/xrpld/app/misc/SHAMapStoreImp.cpp	80.7% <100.0%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ximinez]

TODO:

1. Add a function to DatabaseRotating that is like fetchNodeData, but also includes the "depth" that the node is found at.
2. At the end of the SHAMapStoreImp::run() rotation process, start with the current validated ledger index, then use the existing cond_ to check after every following validated ledger index
3. Look up the hash using LedgerMaster.
4. Find the ledger hash in the node store. It should always be found, but when it's found in the writable DB, then we're done. Details TBD, especially since I'm not sure if the header is written first or last.
5. Once it's found an determined that all the modified nodes for that ledger are written to the writable DB, set lastRotated to that value.

Edit It's better to have lastRotated set too high and have extra data in the DB than it would be to have lastRotated be set too low and have data from that ledger missing from the DB.

Edit 2026-07-08 Another option to consider: After copying nodes from the archive to the writable (visitNodes) before updating lastRotated, If the validated ledger index is not the same as it was when the rotation started (validatedSeq), update validatedSeq, and try again. Probably implement as another loop inside if (readyToRotate). This causes rotation to chase a moving target. The first attempt will copy over the bulk of the needed nodes, but will take a long time. Thus it's likely that the validated ledger will have moved on. The second attempt will only copy the nodes changed between the first attempt and the current validated ledger, a much smaller set. This has a chance of finishing before the validated ledger moves on. If not, try again. The change set will be even smaller. And so on. The biggest risk is that the rotation never finishes in time. That can be handled with some variation of the process described above - specifically, after some number of attempts, only perform healthWait checks after some number of nodes are copied, instead of read. See also: #7763 for a description of the issue with transient objects causing inner nodes to go back to an old state.

[github-actions]

This PR has conflicts, please resolve them in order for the PR to be reviewed.

[github-actions]

All conflicts have been resolved. Assigned reviewers can now start or resume their review.

[github-actions]

This PR has conflicts, please resolve them in order for the PR to be reviewed.

[github-actions]

All conflicts have been resolved. Assigned reviewers can now start or resume their review.

[github-actions]

This PR has conflicts, please resolve them in order for the PR to be reviewed.

[github-actions]

All conflicts have been resolved. Assigned reviewers can now start or resume their review.

[github-actions]

This PR has conflicts, please resolve them in order for the PR to be reviewed.

[github-actions]

All conflicts have been resolved. Assigned reviewers can now start or resume their review.