Handling block re-orgs in the index

[rot13maxi]

Right now, ord scans forward and indexes the chain into its database. You can see the schema for the database tables here. Those tables store the current state of the chain (ie, no history). The index does store block heights mapped to blockhashes, and when it sees that a previous height in the index doesnt match a previous height from bitcoind, it marks the chain as reorg'd and bails.. That means that if there is a re-org, the indexer does not -- and based on the current schema, can't easily -- roll back state from the orphaned blocks are reindex.

While ord index operators could do something completely out of band like snapshot their index every n hours/days, and then if a re-org is detected go and replace their index and re-index the diff, it would be great if the ord index updater could handle rollback and re-index automatically.

It's not obvious to me that there's a good way to do that without storing some amount of previous state in the index. Either a write-ahead-log that can be rewound, or to have a few tables store historic information. I think that would look something like:

• Have a new table that maps blockhash to a list of satspoints that were in outputs in that block
• in any of the tables that map to satspoint (INSCRIPTION_ID_TO_SATPOINT, SAT_TO_SATPOINT), have the value actually be Map<blockheight, satspoint>
• When querying a table that maps to Map<blockheight, satspoint>, we can easily get the "latest" value
• When a rollback is required, we can get the list of satspoints affected by the orphaned block, and then go and remove that "update" from each affected satspoint. Queries will now resolve the last-known value (the "latest value" is now the previous one)

What other mechanisms can we come up with to handle reorgs?

[rot13maxi]

also it looks like redb now has savepoints, so maybe the answer is just "turn those on and provide a hook to rollback"?

[rot13maxi]

this discussion is about how to make the command

[nammaki]

How to fix this error, is there any command

You need to reindex https://github.com/casey/ord/issues/1946 😭

[nammaki]

That's great news. Last time we checked savepoints were not available. I think this makes most sense to look into.

Except @casey commented on the redb savepoints merge when it was made 🤣

[utxosvaldo]

@rot13maxi
A reorg just happened again at height 783830.

I have been keeping index snapshots for this since last reorg, and I can not get them to work either.
Guess we are reindexing from scratch again.

[0attack]

how about at least a quick fix to make the reindex either automatic or suggested by the software when a reorg is detected...

[sbidolach]

It happened again!

[2023-05-09T12:17:10Z ERROR ord::index::updater] Value channel closed unexpectedly
[2023-05-09T12:17:10Z INFO  ord::index::updater] Block receiver disconnected: sending on a closed channel
[2023-05-09T12:17:15Z INFO  ord::index::updater] Block 788838 at 2023-05-08 22:08:10 UTC with 4043 transactions…
[2023-05-09T12:17:15Z WARN  ord::subcommand::server] reorg detected at or before 788837

[SophisticaSean]

Just happened to me today. Wouldn't be such a problem if re-indexing didn't take forever.