runtime: resolve compute budget in check_transaction()#9155
Conversation
1f9b2a7 to
429f0c7
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #9155 +/- ##
=========================================
- Coverage 82.6% 82.6% -0.1%
=========================================
Files 890 890
Lines 320911 320873 -38
=========================================
- Hits 265364 265282 -82
- Misses 55547 55591 +44 🚀 New features to boost your workflow:
|
buffalojoec
left a comment
There was a problem hiding this comment.
The changes lgtm, nice and clean! Just one question about the metrics.
| @@ -142,7 +142,7 @@ impl Bank { | |||
| raise_cpi_limit, | |||
| ) | |||
| } | |||
| }); | |||
| })?; | |||
There was a problem hiding this comment.
Is it worth incrementing error_counters.invalid_compute_budget here instead?
There was a problem hiding this comment.
it doesnt exist yet; we create TransactionErrorMetrics in svm load_and_execute_sanitized_transactions()
There was a problem hiding this comment.
It's in the function signature though.
There was a problem hiding this comment.
oh i never noticed this before, it actually accumulates the svm ones into a parent in runtime. ill make that change, ty!
e78a393 to
bed5ddd
Compare
|
Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis. |
* runtime: resolve compute budget in `check_transaction()` (cherry picked from commit abcf518)
Problem
in implementing simd290 and simd297 it would be convenient if the only errors we had to handle in svm
validate_transaction_nonce_and_fee_payer()were the nonce and feepayer errors because we will have to propagate particular representations for those cases upwardsthe only error other than nonce/feepayer is unwrapping
Result<SVMTransactionExecutionAndFeeBudgetLimits>, constructed in runtimecheck_transactions()Summary of Changes
instead of delivering a malformed compute budget as its own error, transform it into a
Result<CheckedTransactionDetails>error in runtime. the only possible errors are insanitize_and_convert_to_compute_budget_limits(), checking that requested data and heap size values are sanethere are tests in several crates for a
DuplicateInstructionerror, which is not relevant to this pr. this type of error gets resolved much earlier inRuntimeTransaction<SanitizedVersionedTransaction>::try_from()and never makes it into a batch