Record Reorgs in the database

[tiger5226]

When a reorg happens, it is detected by Chainquery and handled such that Chainquery stays at the top of the chain. However, the current state is just that a reorg notification is only logged and not recorded.

We should create a table called reorgs. It should have columns: id, depth, created_at, height, block_hash_list. The block_hash_list should be a json string array of the hashes of the blocks that were removed due to the reorg. This will help investigating after the fact.

Below is where reorgs are checked for and handled.

https://github.com/lbryio/chainquery/blob/master/daemon/processing/block.go#L128-L165

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]

When we do this we should remove the twilio integration. Per @kauffj "Chainquery should just be a utility to extract blockchain data into SQL or other more usable formats." This sort of notification should leverage Chainquery not be part of Chainquery. We have twilio integration for internal-apis and should implement the notification there.

[tiger5226]

@kauffj I thought of a concern with this. Since reorgs happen and go away. There could be a data consistency issue between instances of Chainquery depending on when they were started up and if there was any downtime. 2 instances of Chainquery could have data inconsistencies depending on the variables mentioned. This makes the data unreliable. Is this a concern for you too or should this be ignored as long the DB data is not used in logic.

[kauffj]

That's a very smart point that now makes me a bit ambivalent about this. It does seem like all chainquery installs should create identical states. Though if we think of re-orgs as equivalent to a logging event maybe it's fine. Any comments @lyoshenka ?

[lyoshenka]

i think its fine to log them in a separate table that's just used for this logging purpose

[lyoshenka]

dupe of #48 ?

[tiger5226]

No, this issue is for recording the reorg information in the db.