[FVM] Cleanup metering code#8601
Conversation
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThis PR consolidates separate metering accessors into ChangesMetering API consolidation
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
This comment has been minimized.
This comment has been minimized.
AlexHentschel
left a comment
There was a problem hiding this comment.
Looks good.
There are some suggestions for incrementally improving error documentation. That might be out of scope or not worth the time investment for this PR - not sure, but also with AI it seems that such comments could be quick to add in some cases (unless it's error propagation, wrapping of errors across many implementation levels)
There was a problem hiding this comment.
brief documentation of errors would be great on MeteringResult and MeterComputation, specifically because it seems we are dealing with sentinel errors. Please consider this as very desired but still optional, just in case properly documenting expected error returns would require a large stack of code changes at the lower layers.
There was a problem hiding this comment.
similarly here, documentation of expected error returns would be great (mindset of leaving the code in a better place than it was before in terms of error documentation, even if it's only an incremental incomplete improvement). Yet, not strictly required for this PR to be merged.
| if h.backend.ComputationRemaining(environment.ComputationKindEVMGasUsage) < uint64(limit) { | ||
| return types.ErrInsufficientComputation | ||
| } |
There was a problem hiding this comment.
would it make sense to document this error as being a potential return value in the method description?
| // `computationUsed` can exceed `computationLimit`, since `MeterComputation` increments | ||
| // the usage before checking the limit; guard against underflow | ||
| if m.computationUsed >= m.params.computationLimit { |
There was a problem hiding this comment.
thanks. Great change, avoids underflow problem.
If you have your AI accumulate memory incl. coding guidelines, I found it worth while to point your AI explicitly to this change, tell it to recognize the underflow problem in the old code and always watch out for similar edge cases. In short: subtraction operations on uint types are always potential risks for bugs. Guideline: when subtracting unit types, there should always be a comment inside the code explaining why underflow cannot occur. Absence of such a statement indicates a potential problem and should either be fixed or a sufficient correctness argument be provided by a comment.
|
|
||
| computationUsed, err := env.ComputationUsed() | ||
| meteringResult, err := env.MeteringResult() | ||
| if err != nil { |
There was a problem hiding this comment.
any critical vs benign errors we need to differentiate between here? Brief comment would help (desired but optional)
| computationLimit := executor.txnState.TotalComputationLimit() | ||
|
|
||
| computationUsed, err := executor.env.ComputationUsed() | ||
| meteringResult, err := executor.env.MeteringResult() |
There was a problem hiding this comment.
any critical vs benign errors we need to differentiate between here? Brief comment would help (desired but optional)
|
Thanks for the review @AlexHentschel. I will address most of the comments you have in subsequent PRs. I'm not done with cleaning up metering, and I want to keep PRs small and focused on a single task so that they are easier to digest. I have a PR removing the error on metering results: #8605, All this so that I will be more certain that I am correct when I fix: https://github.com/onflow/flow-go-internal/issues/7126 |
Co-authored-by: Alexander Hentschel <alex.hentschel@flowfoundation.org>
While working on a different issue, I have decided to cleanup the metering code.
This aims to shrink the metering interface while preserving all the current behavior.
Summary by CodeRabbit
MeteringResult(computation used, memory estimate, and computation intensities).MeteringResultstructure and adjusted metering expectations.