-
Notifications
You must be signed in to change notification settings - Fork 59
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
fix: handle "transaction underpriced" and other unknown server error responses #1617
Changes from 5 commits
09080da
adda76a
a47c784
2afe0d1
d7b5d12
4ae8fb1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -281,6 +281,17 @@ defmodule OMG.ChildChain.BlockQueue.Core do | |
:ok | ||
end | ||
|
||
# https://github.com/ethereum/go-ethereum/blob/v1.9.15/core/tx_pool.go#L62-L64 | ||
def process_submit_result( | ||
submission, | ||
{:error, %{"code" => -32_000, "message" => "transaction underpriced"}}, | ||
_newest_mined_blknum | ||
) do | ||
log_tx_underpriced(submission) | ||
:ok | ||
end | ||
|
||
# https://github.com/ethereum/go-ethereum/blob/v1.9.15/core/tx_pool.go#L66-L68 | ||
def process_submit_result( | ||
submission, | ||
{:error, %{"code" => -32_000, "message" => "replacement transaction underpriced"}}, | ||
|
@@ -340,6 +351,15 @@ defmodule OMG.ChildChain.BlockQueue.Core do | |
:ok | ||
end | ||
|
||
# Fallback for unknown server errors: https://eth.wiki/json-rpc/json-rpc-error-codes-improvement-proposal | ||
# Only server errors are handled as they are the only set of errors that we have no control of. | ||
# Returns `:ok` so that BlockQueue can continue and do a retry, similar to a low replacement price error. | ||
def process_submit_result(submission, {:error, %{"code" => code} = error}, _newest_mined_blknum) | ||
when code >= -32_099 and code <= -32_000 do | ||
_ = Logger.error("Submission #{inspect(submission)} resulted in an unknown server error: #{inspect(error)}.") | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we alarm on all error log. If not let's make sure we add alarm on this, either via Datadog parsing the error message or do the direct alarm (?) from code? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good idea! I think we can do with an app alarm when a block submission is pending for more than 2 blocks (since we're aiming for next-block inclusion, but I'll make number configurable in case of too many false panics). Then Datadog can consume this app alarm similar to Since we're losing this visibility because this PR is suppressing the exception, I'll add There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Queue observability size. Hell yeah! |
||
:ok | ||
end | ||
|
||
# | ||
# Private functions | ||
# | ||
|
@@ -612,12 +632,17 @@ defmodule OMG.ChildChain.BlockQueue.Core do | |
end | ||
|
||
defp log_known_tx(submission) do | ||
_ = Logger.debug("Submission #{inspect(submission)} is known transaction - ignored") | ||
_ = Logger.info("Submission #{inspect(submission)} is known transaction - ignored") | ||
:ok | ||
end | ||
|
||
defp log_tx_underpriced(submission) do | ||
_ = Logger.info("Submission #{inspect(submission)} got rejected due to low gas price - ignored") | ||
:ok | ||
end | ||
|
||
defp log_low_replacement_price(submission) do | ||
_ = Logger.debug("Submission #{inspect(submission)} is known, but with higher price - ignored") | ||
_ = Logger.info("Submission #{inspect(submission)} is known, but with higher price - ignored") | ||
:ok | ||
end | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely sure why do we even bother "handling" results. We don't do anything with them, we're just spending effort defining all function headers and then we ... log and return :ok?
I've never understood the purpose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering the same. It turns about the block queue uses these :ok, {:error, ...} returns to determine if the submission was successful or if it needs to retry the submission :(
I don't like it too but it's not a small refactor. I'm kind of unbundling this in #1575 though