-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
realtime indexer failed to insert internal_transactions_indexed_at_transactions #757
Labels
bug 🐛
Something isn't working
chain: ETH ⛓️
Ethereum mainnet issues.
priority: critical 🔨
Urgent issues.
severity: 1 💥
Critical bug that requires immediate attention.
team: architecture
Milestone
Comments
acravenho
added
bug 🐛
Something isn't working
team: architecture
chain: ETH ⛓️
Ethereum mainnet issues.
priority: critical 🔨
Urgent issues.
severity: 1 💥
Critical bug that requires immediate attention.
labels
Sep 18, 2018
sabondano
added a commit
that referenced
this issue
Sep 19, 2018
Why: * Issue #757 was created after we noticed a few constraint violations for the `error` column in the `transactions` table. The constraint violations came about as we attempted to update transactions with a successful status but some value for the error field. The constraint is violated in this scenario because we expect successful transactions to not have an error. (EIP 658)[ethereum/EIPs#658], which apparently is also called (EIP 98)[ethereum/EIPs#98 (comment)] , says that the status should be set to 1 (success) if the outermost code execution succeeded (internal transaction with index 0), or it should be set to 0 (failure) if the outermost code execution failed. We're currently deriving the status from the last internal transaction when in fact we should be deriving it from the first internal transaction. * Issue link: #757 This change addresses the need by: * Editing `Explorer.Chain.Import.update_transactions/2` to set the error for a transaction equal to the error, if any, of the internal transaction with index 0. * Editing `Explorer.Chain.Import.update_transactions/2` to set a transaction's status as successful if it's internal transaction at index 0 doesn't have an error.
ghost
assigned sabondano
Sep 19, 2018
ghost
added
the
in progress
label
Sep 19, 2018
sabondano
added a commit
that referenced
this issue
Sep 19, 2018
Why: * Issue #757 was created after we noticed a few constraint violations for the `error` column in the `transactions` table. The constraint violations came about as we attempted to update transactions with a successful status but some value for the error field. The constraint is violated in this scenario because we expect successful transactions to not have an error. [EIP 658](ethereum/EIPs#658), which apparently is also called [EIP 98](ethereum/EIPs#98 (comment)) , says that the status should be set to 1 (success) if the outermost code execution succeeded (internal transaction with index 0), or it should be set to 0 (failure) if the outermost code execution failed. We're currently deriving the status from the last internal transaction when in fact we should be deriving it from the first internal transaction. * Issue link: #757 This change addresses the need by: * Editing `Explorer.Chain.Import.update_transactions/2` to set the error for a transaction equal to the error, if any, of the internal transaction with index 0. * Editing `Explorer.Chain.Import.update_transactions/2` to set a transaction's status as successful if it's internal transaction at index 0 doesn't have an error.
sabondano
added a commit
that referenced
this issue
Sep 19, 2018
Why: * Issue #757 was created after we noticed a few constraint violations for the `error` column in the `transactions` table. The constraint violations came about as we attempted to update transactions with a successful status but some value for the error field. The constraint is violated in this scenario because we expect successful transactions to not have an error. [EIP 658](ethereum/EIPs#658), which apparently is also called [EIP 98](ethereum/EIPs#98 (comment)) , says that the status should be set to 1 (success) if the outermost code execution succeeded (internal transaction with index 0), or it should be set to 0 (failure) if the outermost code execution failed. We're currently deriving the status from the last internal transaction when in fact we should be deriving it from the first internal transaction. * Issue link: #757 This change addresses the need by: * Editing `Explorer.Chain.Import.update_transactions/2` to set the error for a transaction equal to the error, if any, of the internal transaction with index 0. * Editing `Explorer.Chain.Import.update_transactions/2` to set a transaction's status as successful if it's internal transaction at index 0 doesn't have an error, and as failed if it does. This only applies to pre-Byzantium and Ethereum Classic, for which transaction status is not set from receipts.
ghost
removed
the
in progress
label
Sep 20, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug 🐛
Something isn't working
chain: ETH ⛓️
Ethereum mainnet issues.
priority: critical 🔨
Urgent issues.
severity: 1 💥
Critical bug that requires immediate attention.
team: architecture
Environment
Steps to reproduce
Expected behaviour
Index new blocks
Actual behaviour
💥
The text was updated successfully, but these errors were encountered: