collect metrics on relay success and latency

[dhfang]

Instrument relayer client to collect metrics on relay success/failure counts and relay request latency.

[greptile-apps]

Greptile Summary

This PR instruments the relayer gRPC client with three Prometheus metrics: a success counter, a failure counter (both labeled by chain_id), and a per-attempt duration histogram. The Cosmos runner correctly gates relay metric creation behind spec.MetricsEnabled; the Ethereum runner does not, unconditionally calling iftrelayer.NewMetrics() and registering metrics in the global Prometheus registry regardless of the operator's preference.

• Ethereum runner ignores MetricsEnabled: iftrelayer.NewMetrics() is called unconditionally at line 181 of chains/ethereum/runner/runner.go, unlike the Cosmos runner which guards it with if spec.MetricsEnabled. This will also panic if two Ethereum runners with relay enabled are created in the same process (e.g., in integration tests), because prometheus.MustRegister panics on duplicate registration.

Confidence Score: 4/5

Safe to merge after fixing the unconditional metric registration in the Ethereum runner.

One P1 finding: the Ethereum runner bypasses the MetricsEnabled guard and unconditionally registers relay metrics, inconsistent with the Cosmos runner and liable to panic if two relay-enabled Ethereum runners are created in the same process.

chains/ethereum/runner/runner.go — unconditional iftrelayer.NewMetrics() call needs MetricsEnabled guard

Important Files Changed

Filename	Overview
ift/relayer/metrics.go	New file defining Prometheus Success/Failure counters and Duration histogram for relay operations; uses MustRegister on global registry which panics on duplicate registration.
ift/relayer/client.go	Wires metrics into SubmitTxHash: Duration recorded per attempt, Success on first successful relay, Failure on context cancellation and after all retries exhausted — logic is correct.
chains/cosmos/runner/runner.go	Correctly guards relay metrics creation behind spec.MetricsEnabled before passing to NewGRPCClient.
chains/ethereum/runner/runner.go	Unconditionally calls iftrelayer.NewMetrics() regardless of spec.MetricsEnabled, inconsistent with the Cosmos runner and will panic on duplicate registration in the same process.

Sequence Diagram

sequenceDiagram
    participant Runner
    participant GRPCClient
    participant PrometheusRegistry
    participant RelayerService

    Runner->>GRPCClient: NewGRPCClient(cfg, chainID, metrics)
    GRPCClient-->>Runner: *GRPCClient

    loop up to maxRelayRetries (15)
        Runner->>GRPCClient: SubmitTxHash(ctx, txHash)
        GRPCClient->>RelayerService: Relay(callCtx, RelayRequest)
        GRPCClient->>PrometheusRegistry: Duration.Observe(elapsed)
        alt success
            GRPCClient->>PrometheusRegistry: Success.Inc()
            GRPCClient-->>Runner: nil
        else error
            note over GRPCClient: store lastErr, retry after 3s
        end
        alt ctx cancelled during retry delay
            GRPCClient->>PrometheusRegistry: Failure.Inc()
            GRPCClient-->>Runner: ctx.Err()
        end
    end
    GRPCClient->>PrometheusRegistry: Failure.Inc()
    GRPCClient-->>Runner: error (all retries exhausted)

Loading

Comments Outside Diff (1)

1. chains/ethereum/runner/runner.go, line 181-186 (link)

   Relay metrics ignore MetricsEnabled flag

   iftrelayer.NewMetrics() is called unconditionally here, while the Cosmos runner correctly guards the same call with if spec.MetricsEnabled. This has two consequences: relay metrics are always registered to the global Prometheus registry even when the operator disables metrics, and if two Ethereum runners are constructed in the same process with spec.Relay != nil (e.g., in parallel tests), prometheus.MustRegister will panic on the second registration.

_{Reviews (1): Last reviewed commit: "collect metrics on relay success and lat..." | Re-trigger Greptile}

[greptile-apps]

MustRegister panics on duplicate registration

prometheus.MustRegister panics if the same metric name is registered twice in the default global registry. If NewMetrics() is called more than once in the same process — for example, in integration tests that instantiate a runner for each test case — the second call will panic. Consider using prometheus.Register with an already-registered check, or accepting a prometheus.Registerer as a parameter so callers can use isolated registries for tests.