Document meaning (and expected values) of ledger_index for a freshly-restarted node

[intelliot]

When a server is first started, it will automatically run consensus on its own and close ledgers. However, these ledgers won't necessarily be validated; that depends on the validators you've configured. Until the server syncs with the network, it will maintain a local ledger that has no relation to the one that the trusted validators are validating. In most cases, the server should sync in less than 30 minutes.

When the server restarts, it does not know the state of the network that it's supposed to connect to. It internally creates a new genesis ledger (which is, of course, not validated and is just meant as an internal scratchpad) and continues updating that ledger while, in parallel, it is trying to catch up to the network. Once it catches up, the ledger chain that the server internally created is discarded and it switches to the validated ledger, according to its UNL.

As to why... well, that's because how it was coded. It could have been coded differently (and it could be changed now) to re-load the last ledger it observed as validated and attempt to continue from there (indeed, that is what fast_load tries to do, and what other changes, like forward ledger replay, will do).

Generally, the existence of this ledger chain during startup should be thought of as an internal implementation detail, and can be ignored by most users.

Context: https://github.com/XRPLF/rippled/issues/4335

[intelliot]

@thejohnfreeman might your Forward Ledger Replay work change the behavior here?

[thejohnfreeman]

No, it doesn't. It only affects the acquisition of ledgers. The logic handling the last validated ledger pointer is unchanged.