execution/commitment: record the trunk-preload duration and bytes counters

[lystopad]

Problem

commitment_trunk_preload_duration_seconds_total and commitment_trunk_preload_bytes_total are declared in trunk_pin_metrics.go but never written anywhere in the tree, so both read 0 for the life of the process.

Confirmed on a live Gnosis node with 5.9 days of uptime and 68,732 recorded preload extensions:

commitment_adaptive_pin_extended_total 68732
commitment_adaptive_pin_promoted_total 5137
commitment_branchcache_pinned_entries  118337
commitment_trunk_preload_bytes_total            0   <-- never written
commitment_trunk_preload_duration_seconds_total 0   <-- never written

The neighbouring counters work; only these two are dead. The result is that there is no metric signal for how much work the adaptive pin controller does or how long it spends doing it. That gap was noticed while diagnosing #23066 — a livelock inside ContractTrunkPreloadParallel.Run — where these counters would have been the natural place to see preload time climbing.

Change

Record both at the two places a preload actually runs, covering the parallel and serial paths in each:

• promoteLocked — the initial view for a newly promoted contract.
• runExtensionLocked — the per-block extension step, which is the dominant path in a running node.

A promote whose Run fails has its pins rolled back via Invalidate, so it contributes its duration but no bytes. That is why recordPreload takes the byte count as a parameter instead of reading it back off the preloader.

No behaviour change beyond the counters; no new metric names, cardinality, or hot-path work (both call sites already run once per contract per block under c.mu).

Testing

TDD, red → green. Both tests fail on main with the counters flat at 0:

• TestAdaptivePin_PromoteRecordsPreloadMetrics — both counters advance across a promote.
• TestAdaptivePin_ExtendRecordsPreloadMetrics — both counters advance across an extension, with the initial view budgeted so the queue survives promotion and there is real work left to measure.

Each test guards against a vacuous pass by first asserting the preload actually pinned bytes / left a non-empty queue.

Full execution/commitment/... suite passes. make lint clean for the touched files.

Relationship to #23066

Split out of #23066 review discussion to keep that fix minimal. The two branches touch disjoint files (adaptive_pin.go / trunk_pin_metrics.go here, preload_parallel.go there). Verified by trial-merging the two branches: no conflicts, merged result builds and the full package suite passes. They can land in either order.

[Copilot]

Pull request overview

This PR fixes two previously “dead” Prometheus counters in execution/commitment by recording trunk-preload duration and pinned-bytes whenever the adaptive pin controller actually performs a trunk preload (both initial promote and per-block extensions). This improves observability of the adaptive pin controller’s workload without changing preload behavior or metric cardinality.

Changes:

• Add a small helper (recordPreload) to consistently record preload wall time and newly pinned bytes.
• Instrument both promote and extension paths (serial and parallel) to emit the two counters.
• Add unit tests ensuring both counters advance on promote and on extension (with guards to avoid vacuous passes).

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
execution/commitment/trunk_pin_metrics.go	Adds recordPreload helper to update duration/bytes counters.
execution/commitment/adaptive_pin.go	Records preload duration/bytes around Run calls in promote and extension paths.
execution/commitment/adaptive_pin_test.go	Adds tests verifying the counters advance for promote and extension workloads.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[lystopad]

Fixed the Windows failure in fbce91e.

Both metric tests asserted time.Since(...) > 0 over a preload that takes microseconds. Windows' timer granularity rounds that to zero, so they failed on every Windows run since the branch was first pushed (54937513e, before any sync with main) — macOS and Linux always passed, which is why it went unnoticed. The recent runs surfaced as cancelled rather than failure only because the retry on the failing package now tips the job past its 1h cap.

The product code was fine; the assertion was wrong. Now:

• the two integration tests assert only the byte counter, which still proves recordPreload is wired since nothing else writes it;
• TestRecordPreload_RecordsElapsedAndBytes covers the elapsed time directly with a backdated started, exact on any timer, and also pins that a step which pinned nothing still records its duration.

Verified the new test fails when the duration line is removed from recordPreload. Package green, green under -race -count=2, lint clean.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

execution/commitment/adaptive_pin.go:370

• In the serial extension path, bytesPinned is computed as (state.preload.usedBytes - before). However, ContractTrunkPreload.Run can return an error after pinning some entries without committing chunkUsedBytes into p.usedBytes (it returns early on reader error), while the pinned entries remain in the cache/state for retry. That means failed extension runs can under-report pinned bytes (and behave differently from the parallel path, where usedBytes is incremented per pin), making commitment_trunk_preload_bytes_total inaccurate in the presence of transient reader errors.

	state.preload.pinTxNum = txNum
	before, started := state.preload.usedBytes, time.Now()
	_, _, err := state.preload.Run(stepBudget, reader, c.cache, c.logger)
	recordPreload(started, state.preload.usedBytes-before)
	return err