Skip to content

[FVM] Cleanup metering code#8601

Open
janezpodhostnik wants to merge 4 commits into
masterfrom
janez/metering-cleanup
Open

[FVM] Cleanup metering code#8601
janezpodhostnik wants to merge 4 commits into
masterfrom
janez/metering-cleanup

Conversation

@janezpodhostnik

@janezpodhostnik janezpodhostnik commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

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

  • New Features
    • Execution output now surfaces metering as a single MeteringResult (computation used, memory estimate, and computation intensities).
    • Event collections now expose an event counter instead of total byte size.
  • Bug Fixes
    • Computation remaining no longer underflows and correctly reports exhaustion after over-limit metering attempts.
    • Transaction fee deduction now uses the latest metering summary.
    • Gas/computation sufficiency checks now use remaining computation.
  • Tests
    • Updated tests and mocks to use the new MeteringResult structure and adjusted metering expectations.

@janezpodhostnik janezpodhostnik self-assigned this Jul 8, 2026
@janezpodhostnik janezpodhostnik requested a review from a team as a code owner July 8, 2026 13:24
@github-actions

github-actions Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

@janezpodhostnik janezpodhostnik changed the title Cleanup metering [FVM] Cleanup metering code Jul 8, 2026
@coderabbitai

coderabbitai Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 1c347820-e537-44c5-a3e3-037edde0a348

📥 Commits

Reviewing files that changed from the base of the PR and between ed60df7 and d96d806.

📒 Files selected for processing (1)
  • fvm/meter/computation_meter.go
🚧 Files skipped from review as they are similar to previous changes (1)
  • fvm/meter/computation_meter.go

📝 Walkthrough

Walkthrough

This PR consolidates separate metering accessors into MeteringResult, updates meter implementations and callers, changes EVM gas checks to use remaining computation, and fixes exhausted-limit handling in ComputationRemaining.

Changes

Metering API consolidation

Layer / File(s) Summary
MeteringResult contract and computation limits
fvm/meter/*, fvm/environment/meter.go, fvm/storage/state/*, fvm/environment/event_emitter.go
Adds MeteringResult, removes obsolete metering methods, and prevents computation-remaining underflow.
Meter implementations and adapters
cmd/util/ledger/util/nop_meter.go, fvm/evm/backends/wrappedEnv.go, fvm/evm/testutils/backend.go
Updates meters and wrappers to expose MeteringResult.
Procedure output and execution flow
fvm/fvm.go, fvm/transactionInvoker.go, fvm/evm/handler/*
Moves execution totals into ProcedureOutput.MeteringResult, updates fee deduction, and uses ComputationRemaining for gas checks.
Mocks and test call sites
fvm/environment/mock/*, engine/execution/..., module/chunks/*, integration/internal/emulator/tests/vm_test.go
Regenerates metering mocks and updates test outputs to use nested metering results.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Possibly related PRs

  • onflow/flow-go#8416: Both changes update EVM gas/computation-limit validation in fvm/evm/handler/handler.go.

Suggested labels: Breaking Change, Improvement

Suggested reviewers: turbolent, zhangchiqing, fxamacker

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name Status Explanation Resolution
Title check ❓ Inconclusive The title is related to the change, but it is broad and doesn’t convey the main metering-interface rewrite clearly. Rename it to reflect the primary change, e.g. "[FVM] Refactor metering interface" or "[FVM] Consolidate metering results".
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch janez/metering-cleanup

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@codecov-commenter

codecov-commenter commented Jul 8, 2026

Copy link
Copy Markdown

@blacksmith-sh

This comment has been minimized.

@janezpodhostnik janezpodhostnik requested a review from a team July 9, 2026 17:04

@AlexHentschel AlexHentschel left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Comment thread fvm/environment/meter.go

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +685 to 687
if h.backend.ComputationRemaining(environment.ComputationKindEVMGasUsage) < uint64(limit) {
return types.ErrInsufficientComputation
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it make sense to document this error as being a potential return value in the method description?

Comment on lines +116 to +118
// `computationUsed` can exceed `computationLimit`, since `MeterComputation` increments
// the usage before checking the limit; guard against underflow
if m.computationUsed >= m.params.computationLimit {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread fvm/meter/computation_meter.go
Comment thread fvm/fvm.go

computationUsed, err := env.ComputationUsed()
meteringResult, err := env.MeteringResult()
if err != nil {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any critical vs benign errors we need to differentiate between here? Brief comment would help (desired but optional)

Comment thread fvm/transactionInvoker.go
computationLimit := executor.txnState.TotalComputationLimit()

computationUsed, err := executor.env.ComputationUsed()
meteringResult, err := executor.env.MeteringResult()

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any critical vs benign errors we need to differentiate between here? Brief comment would help (desired but optional)

@janezpodhostnik

Copy link
Copy Markdown
Contributor Author

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,
I want to do some renaming to make it cleared whats going on and I am working on cleaning up the logic behind disabling metering on certain things.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants