-
Notifications
You must be signed in to change notification settings - Fork 82
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
Unclear unwrap inside core execution logic #1769
Labels
Comments
This issue is stale because it has been open 45 days with no activity. Remove stale label or this issue |
This issue was closed because it was stale |
SuperFluffy
added
the
ignore-stale
Override for issues or PRs which should not be removed if stale.
label
Jan 6, 2025
Reopening because it's actively tracked by PR #1772 |
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 18, 2025
## Summary This PR changes the mempool's `builder_queue()` to be infallible. The code previously would return an error if the nonce fetch from the database failed. Now it handles the error case by using the pending's lowest nonce for the account as an educated guess of what nonce to use for transaction priority construction. This is okay since `prepare_proposal()`'s logic will just reject invalid nonces if the mempool's state is out of date due to a bug. ## Background We shouldn't have non-existential issues in the mempool cause failures in the sequencer. ## Changes - Changed mempool `builder_queue()` to be infallible with reasonable fallbacks. ## Testing Manually changed the code path to only use the new logic and watched all tests pass except for those explicitly testing the jitter between the mempool and database (which shouldn't happen if the rest of the code works). The tests in those scenarios only fail due to unmet assertions and not because of panics. ## Changelogs No updates required. ## Related Issues closes #1769 --------- Co-authored-by: Fraser Hutchison <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
astria_sequencer::App::execute_transaction_prepare_proposal
[1] unwraps aResult
. Theexpect
message it provides does not give any indication why unwrapping at that point is acceptable. Tracing it through the stack the error that is being bubbled up comes from a call deep insideastria_sequencer::Mempool::builder_queue
[2] and [3].It is not clear why this
expect
here is acceptable or why it is an invariant of the system that the return value of of the method call is alwaysOk
.1:
astria/crates/astria-sequencer/src/app/mod.rs
Line 589 in ca72c64
2:
astria/crates/astria-sequencer/src/mempool/mod.rs
Line 298 in ca72c64
3:
astria/crates/astria-sequencer/src/mempool/transactions_container.rs
Line 773 in ca72c64
The code that introduced this was #1323.
┆Issue Number: ENG-960
The text was updated successfully, but these errors were encountered: