Order History events in the same confirmation height. #93
Conversation
|
(Included #92 because |
|
The behavior of the RocksDB is relied upon in weird ways, so the biggest worry I have is a re-surfacing of the weird balance-is-off bugs... |
There was a problem hiding this comment.
Tested ACK @ [5bee69f]
I tested a full reindex on testnet4 and signet without any hiccups, and confirmed that same-block transaction history is now properly ordered.
The address history summary functions need a few changes to take advantage of the new schema, but I can add that in a follow up PR.
I also stepped through all of the code that interacts with the tx history database, and couldn't see any obvious problems downstream of the schema change.
(I have a mainnet reindex still in progress, but it hasn't crashed yet!)
|
(re)tested ACK @ [3dab4c7] I completed a full mainnet reindex with the new u16 tx position, and everything looks good so far, including balances on a bunch of heavily-trafficked addresses. |
Fix summary tx ordering
Order History events in the same confirmation height.
REQUIRES RE-INDEX
REQUIRES A LOT OF TESTING
This should fix the ordering of history entries and transactions within the same block/tx.
I think the addition of this data to the rows might cause unforseen consequences... so it needs to be tested thoroughly.
Requires a Re-Index.