rpc: set_validated_blocks lacks request timeout — stalled report endpoint hangs validation_reporter task

[Nexory]

set_validated_blocks in crates/stateless-common/src/rpc_client.rs:593-612 and its caller in bin/stateless-validator/src/workers.rs:161-166 lack any request timeout. A TCP connection to the report endpoint that is accepted but never replies hangs the validation_reporter task indefinitely, silently severing all subsequent upstream reports for the session.

Current code

// crates/stateless-common/src/rpc_client.rs:593-612
pub async fn set_validated_blocks(
    &self,
    blocks: Vec<ValidatedBlock>,
) -> Result<(), ProviderError> {
    let provider = ...;
    provider.client().request("...", (blocks,)).await
    //       ^^^^^^^^^^^^^^^^^^ — no tokio::time::timeout wrapper, no round_robin_with_backoff
}

// bin/stateless-validator/src/workers.rs:161-166
client.set_validated_blocks(reports).await
//                                  ^^^^^ — also no outer timeout

The alloy RootProvider built via connect_http uses reqwest (0.12/0.13) with no default request timeout.

Why this is not covered by existing PRs

• PR fix: bound per-attempt RPC timeout and retry empty get_code responses #129 (merged 2026-04-30) added per_attempt_timeout (default 20s) applied via tokio::time::timeout inside round_robin_with_backoff. set_validated_blocks does not go through that helper, so the new guard does not apply.
• PR feat: add per-method RPC timeout configuration #110 (open since 2026-03-31) adds block_timeout, witness_timeout, code_timeout as per-method configuration. It does not add a report/set_validated_blocks timeout.
• The module-level doc at line 12 explicitly states "set_validated_blocks is unthrottled" — confirming this is the intended design, not an oversight. But the security/operational consequence of "unthrottled" extending to "no timeout at all" appears unintended given the parallel evolution of per_attempt_timeout on the other methods.

Impact

The validation_reporter is a separate task::spawn (workers.rs:55), so the main block validation pipeline is unaffected. What actually happens on a hung report call:

1. The reporter task's loop blocks on the .await indefinitely.
2. All subsequent validation reports for the session are silently dropped — upstream monitoring/coordination sees the validator go quiet without explicit error.
3. At shutdown (workers.rs:106), the reporter JoinHandle is awaited under a 3-second tokio::time::timeout. The handle does not resolve (the inner .await is still hung), so shutdown proceeds after the 3-second budget, leaving the task running until process exit.

The net effect: silent loss of all upstream reports for the rest of the session, plus a noisy shutdown.

Suggested fix

Three options, increasing in invasiveness:

1. Caller-side timeout (minimal):

   // workers.rs:161-166
   match tokio::time::timeout(
       Duration::from_secs(30),
       client.set_validated_blocks(reports),
   ).await { ... }

2. Reuse per_attempt_timeout inside set_validated_blocks:

   tokio::time::timeout(
       self.config.per_attempt_timeout,
       provider.client().request(...).await,
   ).await

3. Route set_validated_blocks through round_robin_with_backoff with n=1 (no retry). This reuses the existing per_attempt_timeout machinery and keeps the timeout policy centralized.

Option 2 is the smallest patch that fixes the root cause; option 3 is the cleanest architectural fit.

Secondary observation (related, informational)

The module-level doc at rpc_client.rs:21-25 claims: "every public method has a _with_deadline variant that takes an Option<Instant>." This is not quite accurate: get_block_unchecked (lines 460-469) has no _with_deadline companion. Worth either adding one (for trace-server callers that may want a bounded wait) or amending the module doc to note get_block_unchecked as an intentional exception.

[Troublor]

@mega-putin checkout this issue

[mega-putin]

1. Understanding: The issue is asking us to stop a hung mega_setValidatedBlocks RPC call from wedging the background validation_reporter for the rest of the process. The validator pipeline itself should remain unaffected, but report delivery needs a bounded wait so the reporter can log the failure and try again on the next interval.

2. Approach:

   • In crates/stateless-common/src/rpc_client.rs, update RpcClient::set_validated_blocks to wrap the single provider.client().request("mega_setValidatedBlocks", ...) call in tokio::time::timeout(self.config.per_attempt_timeout, ...).
   • Reuse the existing per_attempt_timeout config instead of adding a new knob, so reporting inherits the same stalled-connection protection already used by the other RPC paths.
   • Keep set_validated_blocks as a single-attempt call that returns an error on timeout, rather than routing it through round_robin_with_backoff; the reporter loop in bin/stateless-validator/src/workers.rs already handles errors by logging and retrying on the next tick.
   • In workers.rs, keep the caller simple and rely on the client-level timeout, but make sure timeout failures are logged clearly enough to distinguish them from ordinary RPC rejections.
   • Add a regression test in crates/stateless-common/src/rpc_client.rs that points report_api at a TCP listener which accepts connections and never replies, then asserts set_validated_blocks returns within the configured timeout instead of hanging.
   • Tighten the module docs at the top of rpc_client.rs to avoid overstating the _with_deadline coverage; for this issue I would amend the doc comment rather than expanding the API surface with a new get_block_unchecked_with_deadline.

3. Risks:

   • The main semantic trap is accidentally using round_robin_with_backoff unchanged for reporting: with one report endpoint and no overall deadline, that would retry forever and still block the reporter loop.
   • We should preserve current behavior where a failed report does not fail the validator, only the background reporter iteration.
   • There is a small judgment call on whether report RPC deserves its own dedicated timeout config later; for this fix, reusing per_attempt_timeout keeps scope minimal and behavior consistent.

Reply @mega-putin go to start implementation.

[flyq]

@mega-putin go

[mega-putin]

🚀 PR created: #143