fix(operator): configurable confirmation poll interval and permanent RPC error handling

[Huzaifa696]

Problem

Two hardcoded assumptions in the per-transaction hot path for deposit/withdraw were capping the throughput:

1. check_transaction_status used a fixed 1000 ms poll interval. Contra's block time is ~100 ms, so the operator waited 10× longer than necessary to detect confirmation.
2. The mint idempotency check (getSignaturesForAddress) retried 5 times with exponential backoff, burning ~1500 ms per transaction — even though the Contra RPC node returns -32601 Method not found, a response that will never change between attempts.

Changes

• Configurable poll interval: replaces the hardcoded POLL_INTERVAL_MS_CONFIRMATION = 1000 with confirmation_poll_interval_ms in OperatorConfig (default: 400 ms, matching Solana's block time). All deployment configs are updated: operator-solana uses 100 ms; operator-contra uses 400 ms.

• Permanent RPC error short-circuit: with_retry now exits immediately on -32601 Method not found rather than exhausting the backoff budget. The check is scoped to this specific JSON-RPC error code so all other errors continue to retry as before. A TODO marks the guard for removal once getSignaturesForAddress is implemented on the RPC node.

Impact

TPS	Before	After	improvement
Deposit	~0.4	~9	22x
Withdraw	~1	~2.5	2.5x

Results

Deposit

Withdraw

Coverage Report

Component	Lines Hit	Lines Total	Coverage	Artifact
Core	7,103	8,411	84.4%	rust-unit-coverage-reports
Indexer	12,135	14,212	85.4%	rust-unit-coverage-reports
Gateway	952	1,076	88.5%	rust-unit-coverage-reports
Auth	541	596	90.8%	rust-unit-coverage-reports
Withdraw Program	-	-	-	-
Escrow Program	-	-	-	-
E2E Integration	7,687	11,041	69.6%	e2e-coverage-reports
Total	28,418	35,336	80.4%

Last updated: 2026-04-06 19:32:36 UTC by E2E Integration

[greptile-apps]

Greptile Summary

This PR replaces the hardcoded POLL_INTERVAL_MS_CONFIRMATION = 1000 ms constant in check_transaction_status with a configurable confirmation_poll_interval_ms field on OperatorConfig, defaulting to 400 ms (matching Solana's block time) and overridable to 100 ms for Contra-chain operators. The change is cleanly threaded through run_sender → SenderState → check_transaction_status and all deployment configs are updated.

• Core change: transaction_util.rs drops the hardcoded constant; check_transaction_status now accepts poll_interval_ms as an explicit parameter
• Config: DEFAULT_CONFIRMATION_POLL_INTERVAL_MS = 400 is defined in config.rs; operator-contra.toml files use 400 ms, operator-solana.toml files use 100 ms, reflecting each side's monitored chain block time
• Propagation: Config field is correctly wired from OperatorSection (bin) → OperatorConfig → run_sender → SenderState → check_transaction_status
• Behavior change: The effective default polling frequency changes from 1 000 ms to 400 ms for any deployment that doesn't explicitly set confirmation_poll_interval_ms
• Tests: All test fixtures updated to 400 — except for two run_sender unit tests in sender/mod.rs which still pass the legacy 1000 literal

Confidence Score: 5/5

Safe to merge — purely additive config change with a sensible default; no logic regressions found

The change is a clean, well-scoped refactor. The 400 ms default is more appropriate than the old 1 000 ms hardcoded value and is correctly tuned per deployment environment. The only finding is a minor test-fixture inconsistency in sender/mod.rs that does not affect correctness or coverage.

No files require special attention; indexer/src/operator/sender/mod.rs has a trivial test-fixture inconsistency

Important Files Changed

Filename	Overview
indexer/src/operator/utils/transaction_util.rs	Removes hardcoded 1000ms constant; adds poll_interval_ms parameter to check_transaction_status, correctly passed at all call sites and tests
indexer/src/config.rs	Adds confirmation_poll_interval_ms field to OperatorConfig with DEFAULT_CONFIRMATION_POLL_INTERVAL_MS = 400 constant and serde default function
indexer/src/operator/sender/mod.rs	Threads confirmation_poll_interval_ms through run_sender; two unit test fixtures still use the legacy 1000 ms literal instead of the new constant
indexer/src/operator/sender/types.rs	Adds confirmation_poll_interval_ms: u64 field to SenderState struct with a clear doc comment
indexer/src/operator/sender/transaction.rs	Forwards state.confirmation_poll_interval_ms to check_transaction_status at the correct call site
indexer/src/bin/indexer.rs	Adds confirmation_poll_interval_ms to OperatorSection deserialization struct with a default function referencing the exported constant
indexer/config/local/operator-contra.toml	Sets confirmation_poll_interval_ms = 400 (Solana monitoring) and reduces poll_interval_secs to 1
indexer/config/local/operator-solana.toml	Sets confirmation_poll_interval_ms = 100 (Contra monitoring) with increased batch_size and channel_buffer_size

Sequence Diagram

sequenceDiagram
    participant Cfg as OperatorConfig
    participant Op as operator::run
    participant S as run_sender
    participant SS as SenderState
    participant T as send_and_confirm
    participant U as check_transaction_status
    Cfg->>Op: confirmation_poll_interval_ms
    Op->>S: confirmation_poll_interval_ms
    S->>SS: SenderState::new(…, confirmation_poll_interval_ms)
    SS-->>S: state.confirmation_poll_interval_ms stored
    S->>T: handle_transaction_submission(state, …)
    T->>U: check_transaction_status(rpc, sig, commitment, policy,<br/>state.confirmation_poll_interval_ms)
    loop up to MAX_POLL_ATTEMPTS_CONFIRMATION (5)
        U->>U: getSignatureStatuses RPC call
        U->>U: sleep(poll_interval_ms)
    end
    U-->>T: ConfirmationResult

Loading

_{Reviews (1): Last reviewed commit: "feat(operator): configurable confirmatio..." | Re-trigger Greptile}