feat(simulation): in-process meter_bundle on mempool (5/n)

[wlawt]

Motivation

Sim workers need to call meter_bundle on the mempool process without a JSON-RPC hop. Today that logic only lives inside base_meterBundle.

Changes

• Extract MeteringApiImpl::meter_parsed_bundle / meter_transaction as the in-process API
• Add ParsedBundle::from_recovered for a single recovered tx
• --enable-inline-simulation enables MeteringExtension even without --enable-metering
• RPC base_meterBundle now wraps the extracted method
• No workers, no RPC switch; eth_sendRawTransaction still uses add_transaction

Stacked on #4602.

Tests

Test Name	Description
from_recovered_wraps_a_single_transaction	One recovered envelope becomes a one-tx bundle
inline_simulation_enables_metering_without_enable_metering_flag	Inline-sim flag turns metering on
forwarding_without_inline_simulation_leaves_metering_disabled	Forwarding-only mempool does not enable metering
in_process_meter_transaction_uses_mempool_state	Direct meter_transaction on harness state returns 21000 gas + execution time

Made with Cursor

[github-actions]

Review Summary

PR: feat(simulation): in-process meter_bundle on mempool (5/n)

This PR extracts the metering logic from the RPC handler into reusable in-process methods (meter_parsed_bundle, meter_transaction) and adds ParsedBundle::from_recovered for single-tx bundles. The refactor is clean and introduces a proper MeterBundleError enum to preserve RPC error code semantics.

Block Production Sensitivity

This PR touches metering paths but the changes are on the read-only simulation side, not in the payload assembly/finalization critical path. The meter_parsed_bundle / meter_transaction methods perform EVM simulation against existing state — they do not participate in block building, flashblock publishing, or payload finalization. No block-production halt/stall risk identified.

Findings

No new findings beyond the two inline comments already posted:

1. RPC error semantics change (Nit): get_l1_block_info provider errors now map to Internal via the From<eyre::Error> blanket impl rather than explicitly. The InvalidParams cases for "Block not found" and "Block has no transactions" are correctly preserved.

2. RPC surface exposure (Low): Already noted — --enable-inline-simulation does not enable metering RPC (confirmed by test inline_simulation_does_not_enable_metering_rpc). The metering_config function correctly returns disabled() unless --enable-metering is set.

Notes

• The MeterBundleError enum and From<eyre::Error> impl are well-structured. The ? operator in meter_parsed_bundle_result correctly funnels eyre::Error from meter_bundle() into Internal.
• The public meter_parsed_bundle method erases the InvalidParams/Internal distinction by converting back to eyre::Error. This is fine for in-process callers who don't need RPC error codes.
• Test coverage is good: error mapping tests, in-process metering test, and CLI flag interaction tests all validate the expected behavior.
• PR description says --enable-inline-simulation "enables MeteringExtension even without --enable-metering" but the code and tests show the opposite — this is a description inaccuracy, not a code issue.

[github-actions]

Base Std historical fork tests

Fork	Result	Passed	Failed	Skipped	base/base	base-anvil	base-std
Beryl	pass	616	0	13	00586642	8d0f5b8a	4658f1b7
Cobalt	pass	721	0	14	00586642	9df661bc	e30b3421

View run

[github-actions]

Caution

This PR may regress performance. 1 benchmark(s) slower by more than 10% beyond the noise band: batch_transaction_encoding/temporary_frame_buffers (+30.5%).

Benchmark results (advisory)

Median time on the PR head versus the base branch, measured on the same host. Wall-clock, so a change is only flagged when it clears ±10% and the confidence intervals do not overlap. Only benchmarks past the ±10% threshold (plus new or dropped ones) are listed. This check never blocks a merge.

Benchmark	Base	Head	Δ median
batch_transaction_encoding/temporary_frame_buffers	230.14 µs	300.35 µs	+30.5% ⚠️ slower
execution/Open 1024 nodes - 65,536 nodes	76.91 µs	58.14 µs	-24.4% ✅ faster

47 benchmark(s) within ±10% omitted.

View run · Re-run benchmarks