docs(remediation): correct why two chain claims had no DB row - #65
Merged
Conversation
The generator blamed claimAction's (created_tx, action_id, claimer_id) dedup guard collapsing two claimactions sent in one transaction. Checked against /v1/history/get_actions: both cases (chain 19871 and 19904) are two SEPARATE transactions that landed in the SAME block, same claimer, same action, identical proof_photo — a double submit. Different created_tx, so that guard never matched them and is not the cause. The likelier mechanism is the old serial fallback: a truncated chain read made the resolver give up, the serial it fell back to collided with an id already taken, and the insert's `.catch(e => logError(...))` swallowed the failure so the row disappeared without stopping the block. Dropping the fallback closes that path. Also records that the backfilled rows leave created_block/created_tx/ created_eos_account NULL and must be filled from the history API afterwards: the GraphQL :claim type marks them non_null, so a single NULL row nullifies a validator's entire claims list in the Elm app. Hit exactly that on prod today after running the remediation; both rows have since been backfilled from /v1/history/get_actions and prod-anomaly-check.sh is clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #61, from running the remediation on prod today.
The cause was misattributed. The generator blamed
claimAction's(created_tx, action_id, claimer_id)dedup guard collapsing two claimactions sent in one transaction. Checked against/v1/history/get_actions: both cases (chain 19871 and 19904) are two separate transactions in the same block — same claimer, same action, identicalproof_photo, i.e. a double submit. Differentcreated_tx, so that guard never matched them.The likelier mechanism is the old serial fallback: a truncated chain read made the resolver give up, the serial it fell back to collided with an id already taken, and the insert's
.catch(e => logError(...))swallowed the failure so the row vanished without stopping the block. #61 removes the fallback.Operational note added. The backfill INSERT leaves
created_block/created_tx/created_eos_accountNULL, and the GraphQL:claimtype marks them non_null — one NULL row nullifies a validator's whole claims list in the Elm app. That fired on prod today;scripts/prod-anomaly-check.shcaught it immediately after the remediation. Both rows were backfilled from the history API and the check is clean again.Comment-only; no behaviour change.