grod220
commented
1 month ago Spent a bit of time thinking about this today. In order to make the remaining saves atomic, we need:
- A staging area for saves
- Updates in-block db getters to look in staging area prior to db
Idb has support for atomic updates. We make use of it for tct updates. However, the staging area is important. We need a way to queue up all of the save actions that can later (within that same block) be accessed as if they were already committed.
For example, the infamous auction upsert loop. The comment + code placement is there because it depends on the auction NFT metadata already saved in the database before it can associate a note with the NFT.
Another example is handling epoch transitions. It relies upon requesting the appParams from the database. However, the block could have updated these. In an atomic world, it would not know for sure without checking the staging area first.
Queuing up saves (and at the end committing them all at once) is definitely possible. But I believe we need to add a staging area and update the getters to reference these prior to database lookups.
TalDerei
processing blocks in the block processor isn't actually atomic, introducing the possibility of local state corruption.
references this comment