Ord only creates savepoints if the number of blocks indexed is a multiple of 10 (or if it's less than 10, for some reason) when it commits to the db.

If I start indexing from scratch, interrupt the process within the first 5k blocks, then resume indexing, it's quite likely that I don't get any savepoints created.

Let's say I interrupted it after indexing 1234 blocks. A commit is done at that point, but 1234 isn't a multiple of 10 so no savepoint is created. When I resume indexing, a commit happens every 5000 blocks: after 6234 blocks, 11234 blocks, 16234 blocks, etc. None of those are multiple of 10 either.

I only get a savepoint if I am lucky enough to run the indexer when the block height ends with 9, which is 10% of the time.

Then, when a reorg happens I get a crash: "panicked at Option::unwrap()" when get_persistent_savepoint finds no savepoints.

It would be better if update_savepoints() created a savepoint if it has been 10 or more blocks since the last savepoint was made, whether or not the number of blocks indexed is a multiple of 10.

detect_reorg() assumes that savepoints happen every 10 blocks, but that isn't the case unless ord is running in server mode.