Improve tx tracer timing of inclusion metrics

[henridevieux]

Small Improvement to the accuracy of tx inclusion metrics emitted from txpool tracer, by capturing the timestamp a block or flashblock was received, rather than when the tx was processed by the tracer.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[github-actions]

The PR goal is to capture the timestamp when the block/flashblock notification is received from the stream, not when the tracker processes it. But Instant::now() is called here inside track_committed_chain, which runs after handle_canon_state_notification dispatches to it. Consider capturing the timestamp in the public entry points (handle_canon_state_notification / handle_flashblock_notification) or even in the tokio::select! branch in tracex_subscription before any processing occurs. As written, this still includes processing overhead from the handle_* method call chain (minor), and the name received_at is slightly misleading — it's really "processing started at."

The same applies to track_flashblock_transactions at line 95.

This is a minor point since the delta is small in practice, but if accuracy of the "received" timestamp matters (as the PR title suggests), hoisting it to the tokio::select! arms in subscription.rs would be more precise:

// in tracex_subscription
Some(Ok(notification)) = canonical_stream.next() => {
    let received_at = Instant::now();
    tracker.handle_canon_state_notification(notification, received_at);
}

[github-actions]

Review Summary

Clean, well-scoped change. The PR correctly captures Instant::now() in the tokio::select! arms in subscription.rs (lines 48, 54) before passing it through to the tracker methods, which addresses the stated goal of measuring inclusion latency from notification receipt rather than from processing time.

The change is appropriately limited to block/flashblock inclusion paths. Mempool pool-movement events (transaction_moved, transaction_replaced) continue to use inline Instant::now(), which is correct since those events are processed synchronously in their own select! arm without intermediate processing delay.

No correctness, safety, or performance concerns found.

Note on the existing inline comment: The prior bot comment on tracker.rs suggests hoisting the timestamp capture to the tokio::select! arms — but the PR already does exactly that in subscription.rs. The recommendation in that comment is already implemented.