Skip to content
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

Closed
acravenho opened this issue Sep 18, 2018 · 0 comments · Fixed by #762
Closed

realtime indexer failed to insert internal_transactions_indexed_at_transactions #757

acravenho opened this issue Sep 18, 2018 · 0 comments · Fixed by #762
Assignees
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
Copy link
Contributor

19:36:00.344 application=indexer [error] realtime indexer failed to insert internal_transactions_indexed_at_transactions for block 6357162: %{exception: %Postgrex.Error{connection_id: 38087, message: nil, postgres: %{code: :check_violation, constraint: "error", detail: "Failing row contains (1080365, Reverted, 2039000, 35088387070, 30473, \\x033fe648d88b2fa642d861c40b12cca20fdbe0d663c174a0bd7623b5d79214..., 12, \\x0cf9075001e1611da9ca3906a07a0a529ad03ac559a17cff4755ddf09e257f..., 2018-09-18 23:35:32.17256, 13302, 1153330021883541804366647502123718147749272098158759502836410991..., 4196848858900281870087641895703590288210838581276061365965369036..., 1, 38, 0, 2018-09-18 23:35:32.17256, 2018-09-18 23:35:32.17256, \\x1f1f00b6e9e54d16cd6c10cab016813e8c9035f5dda60f3b975e55008efc23..., 6357162, \\x75cccb881435f15818f8698fcb0219186907d26a, \\xae6814472dac803b82d4ea4588cf7af8b2b12d1d, null).", file: "execMain.c", line: "2055", message: "new row for relation \"transactions\" violates check constraint \"error\"", pg_code: "23514", routine: "ExecConstraints", schema: "public", severity: "ERROR", table: "transactions", unknown: "ERROR"}}, transaction_hashes: [%Explorer.Chain.Hash{byte_count: 32, bytes: <<3, 63, 230, 72, 216, 139, 47, 166, 66, 216, 97, 196, 11, 18, 204, 162, 15, 219, 224, 214, 99, 193, 116, 160, 189, 118, 35, 181, 215, 146, 20, 143>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<3, 140, 88, 71, 133, 96, 221, 37, 224, 220, 184, 75, 2, 230, 254, 131, 122, 177, 155, 196, 175, 114, 159, 203, 84, 63, 36, 209, 123, 7, 122, 103>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<7, 229, 127, 133, 198, 228, 239, 134, 235, 167, 53, 225, 247, 11, 27, 186, 242, 129, 173, 39, 101, 104, 157, 145, 8,9, 106, 189, 144, 99, 61, 167>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<13, 66, 141, 129, 46, 76, 9, 215, 236, 187, 171, 80, 91, 4, 121, 78, 20, 250, 49, 244, 164,30, 244, 28, 5, 78, 141, 75, 135, 126, 81, 143>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<13, 203, 113, 223, 112, 250, 247, 121, 245, 67, 134, 73, 100, 58, 98, 248,37, 61, 24, 198, 22, 147, 10, 102, 119, 199, 186, 17, 135, 54, 230, 129>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<23, 11, 74, 251, 121, 226, 12, 97, 106, 125, 7, 134, 240, 186, 190, 72, 5, 233, 206, 164, 85, 126, 55, 61, 139, 16, 176, 111, 31, 10, 104, 2>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<28, 253, 128, 107, 34, 255, 81, 62, 245, 125, 128, 200, 107, 57, 197, 179, 208, 238, 241, 111, 11, 149, 83, 173, 234, 69, 2, 212, 183, 26, 161, 62>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<30, 64, 10, 194, 71, 175, 205, 56, 23, 136, 239, 159, 160, 8, 12, 89, 136, 3, 152, 101, 149, 6, 95, 89, 154, 162, 116, 194, 54, 242, 51, 121>>}, %Explorer.Chain.Hash{byte_count:32, bytes: <<57, 39, 253, 146, 2, 255, 206, 11, 251, 116, 68, 19, 116, 128, 203, 77, 144, 83, 244, 186, 207, 116, 245, 151, 122, 120, 134, 209, 128, 43, 21, 12>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<71, 76, 8, 152, 60, 209, 22, 175, 191, 8, 182, 88, 156, 90, 111, 48, 94, 122, 246, 192, 122, 112, 181, 75, 192, 175, 119, 65, 17, 67,82, 173>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<92, 177, 174, 10, 237, 79, 117, 255, 6, 126, 149, 121, 182, 141, 184, 98, 138, 68, 134, 238, 218, 61, 188, 45, 228, 147, 75, 191, 80, 37, 161, 201>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<99, 207, 124, 229, 85, 176, 164, 90, 146, 112, 166, 255, 65, 251, 207, 8, 57, 114, 141, 132, 208, 170, 48, 25, 55, 22, 67, 136, 143, 70, 70, 23>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<112, 213, 11, 174, 50, 18, 68, 255, 78, 162, 82, 100, 54, 211, 0, 235, 247, 177, 188, 197, 83, 154, 214, 40, 193, 251, 99, 141, 184, 194, 50, 140>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<139, 83, 96, 58, 107, 104, 159, 243, 184, 239, 225, 62, 104, 219, 214, 177, 103, 123, 27, 28, 180, 110, 173, 151, 46, 78, 205, 147, 91, 48, 79, 234>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<149, 140, 111, 232, 174, 13, 33, 203, 50, 69, 55, 38, 37, 20, 139, 12, 252, 190, 28, 242, 247, 233, 61, 25, 35, 99, 71, 65, 41, 222, 97, ...>>}, %Explorer.Chain.Hash{byte_count: 32, bytes:<<190, 89, 203, 149, 2, 230, 204, 113, 70, 98, 175, 203, 123, 25, 64, 24, 58, 166, 193, 248, 54, 33, 142, 0, 238, 44, 89, 36, 194, 116, ...>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<200, 149, 99, 89, 128, 174, 226, 34, 232, 249, 91, 59, 127, 237, 145, 83, 253, 132, 222, 16, 200, 109, 207, 2, 159, 63, 40, 56, 72, ...>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<221, 189, 212, 215, 188, 7, 145, 183, 231, 255, 177, 48, 246, 84, 104, 20, 81, 195, 56, 63, 72, 132, 237, 9, 235, 161, 145, 113, ...>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<230, 147, 219, 60, 202, 199, 21, 46, 207, 253, 147, 179, 16, 173, 50, 24, 58, 163, 5, 195, 198, 116, 31, 69, 139, 89, 214, ...>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<235, 218, 197, 243, 249, 25, 221, 29, 78, 28, 138, 231, 254, 149, 198, 85, 89, 106, 5, 23, 207, 129, 76, 103, 140, 0, ...>>}, %Explorer.Chain.Hash{byte_count: 32, bytes: <<244, 47, 203, 52, 176, 45, 127, 2, 210, 54, 73, 142, 195, 217, 2, 77, 209, 221, 188, 170, 71, 203, 165, 6, 5, ...>>}]}.  Block will be retried by catchup indexer.

Environment

  • Operating System: Linux

Steps to reproduce

  1. Index ETH mainnet
  2. Realtime indexer immediately fails

Expected behaviour

Index new blocks

Actual behaviour

💥

@acravenho 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
@acravenho acravenho added this to the Kuala Lumpur milestone 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 ghost assigned sabondano Sep 19, 2018
@ghost 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 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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants