reorg block with claim update will remove claim

[tiger5226]

When we update a claim, we update the outpoint it came from which will point to the latest update of the claim. If that update is part of a transaction in a block that is orphaned from a reorg, it will also delete the the claim since it is tied to the outpoint of the last update.

Ideally, claim versioning could prevent this problem as then only the claim version would be impacted by the reorg, which is what we would expect.

For the near term, I need to think about this one. What we might want to do, is in the event this happens, the claim will be missing. So if we get an update for a claim that doesn't exist, we should create instead of posting a warning to the logs. This is not a terrible idea because it is assumed that if there is an update in a transaction, that the blockchain has already validated this and it has the claim in the claimtrie.

This is a very RARE scenario. 1 block reorgs, happen 1 per week if that, and the chance that a block contains a claim update is also pretty rare. So together this will probably not happen in production any time soon and if it does, it is such a tiny fraction of the overall claims.

I only found this debugging another issue, where I had to delete 5k blocks which is what a reorg does when it orphans blocks.

Acceptance Criteria

Definition of Done

• Tested against acceptance criteria
• Tested against the assumptions of the user story
• The project builds without errors
• Unit tests are written and passing
• Tests on devices/browsers listed in the issue have passed
• QA performed & issues resolved
• Refactoring completed
• Any configuration or build changes documented
• Documentation updated
• Peer Code Review performed

[tiger5226]

@lyoshenka This is basically the claim version question as well. How do we want to handle claim versions. One proposal was to have versions and then the claim table. The claim table is alway up to date and you can check versions in the version table.

However, in this case, a reorg would remove the claim because it is tied to the transaction it was last updated with. This is certainly useful for setting bid_state. However, we should come up with a solution for this too. We could have a sync job that looks for this and creates the claim again and ties it to the transaction of the latest version if we have the claim version table. Do you have any immediate thoughts on this? I can think more in depth about it as well.

[lyoshenka]

Its fine to remove claims from chainquery if the transaction containing the claim is removed from the blockchain.

I'm happy to talk architecture details. Can you write down how chainquery deals with reorgs now, maybe with diagrams? I have some thoughts on how it should work but it would help to understand what happens now.

[alyssaoc]

moving to groomed for tech design,
created epic, add additional issues for implementation

[tiger5226]

added issue for technical design