-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Handle terminally stuck transactions on send #14127
Changes from 5 commits
415ae2b
ed80b43
321c21a
6003fed
67270d1
d786f17
9af6dee
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 |
---|---|---|
@@ -0,0 +1,5 @@ | ||
--- | ||
"chainlink": minor | ||
--- | ||
|
||
Added client error classification for terminally stuck transactions in the TXM #internal |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -596,6 +596,11 @@ func ClassifySendError(err error, clientErrors config.ClientErrors, lggr logger. | |
) | ||
return commonclient.ExceedsMaxFee | ||
} | ||
if sendError.IsTerminallyStuckConfigError(configErrors) { | ||
lggr.Criticalw("Transaction that would have been terminally stuck in the mempool detected on send. Marking as fatal error.", "err", sendError, "etx", tx) | ||
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. Shouldn't be critical log. Should be a warning. A stuck tx is now an expected behavior, so warn log is enough. 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. Will do! I was just trying to match the behavior for Fatal. Think we're planning to rework logs in the near future so that might change anyways |
||
// Attempt is thrown away in this case; we don't need it since it never got accepted by a node | ||
return commonclient.TerminallyStuck | ||
} | ||
lggr.Criticalw("Unknown error encountered when sending transaction", "err", err, "etx", tx) | ||
return commonclient.Unknown | ||
} |
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.
whats the criteria for a Error log vs a Critical log?
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.
from my understanding this (tx stuck due to overflow,
not enough keccak counters to continue the execution)
is expected behavior, as least for zkSync. When it happens we just need to cancel/purge the existing tx by reprocessing, and it's not critical/fatal issue related to chainlink node that we need to raise alert, critial/fatal one for example:Invariant violation: fatal error while re-attempting transaction
should not happenThere 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.
That's my understanding as well. Since the TXM resolves this on its own, we don't have to raise a signal for NOPs to take any actions.
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.
Agree. I would say, change log level also to a warn.
The Tx is bad, and is nothing wrong with the TXM.