nautechsystems/nautilus_trader · error
debug_traceTransaction request failed
Error message
debug_traceTransaction request failed
What it means
`probe_call_trace` maps any transport error from its test `debug_traceTransaction` request that is not a rejected redirect to this generic "request failed" error, re-wrapping the underlying `BlockchainRpcClientError`. It signals the probe could not complete a successful HTTP exchange, so the endpoint's callTracer support could not be verified.
Source
Thrown at crates/adapters/blockchain/src/rpc/http.rs:827
{
"tracer": "callTracer",
"tracerConfig": {
"onlyTopCall": false,
"withLog": false,
},
}
],
});
let bytes = self
.send_rpc_request(request, Some(EXECUTION_RPC_TIMEOUT_SECS))
.await
.map_err(|e| match e {
BlockchainRpcClientError::ClientError(message)
if message.contains("redirect response rejected") =>
{
anyhow::anyhow!("debug_traceTransaction redirect rejected")
}
_ => anyhow::anyhow!("debug_traceTransaction request failed"),
})?;
let parsed =
serde_json::from_slice::<RpcNodeHttpResponse<serde_json::Value>>(bytes.as_ref())
.map_err(|_| anyhow::anyhow!("Failed to parse debug_traceTransaction response"))?;
if parsed.jsonrpc.is_none()
&& let (Some(code), Some(_)) = (parsed.code, parsed.message)
{
return trace_probe_result(code);
}
if let Some(error) = parsed.error {
return trace_probe_result(error.code);
}
anyhow::ensure!(
parsed.result.is_some(),
"debug_traceTransaction returned no result"
);
Ok(())View on GitHub (pinned to 18893faf8b)
Solutions
- Check node reachability: curl the endpoint with a trivial eth_chainId request
- Confirm the `debug` API namespace is enabled (e.g. geth `--http.api ...,debug` or erigon trace namespace)
- Look at the wrapped source error for the precise cause (timeout vs refused vs HTTP status)
- Retry or move the probe/tracing to a dedicated trace-enabled node
Example fix
// before: debug namespace disabled -> probe request fails // geth flags: --http.api eth,net // after: enable debug/trace namespace // geth flags: --http.api eth,net,debug // erigon flags: --http.api eth,erigon,trace
Defensive patterns
Strategy: try-catch
Validate before calling
async fn debug_api_available(url: &str) -> bool {
// any successful debug_* round trip proves the namespace is enabled
send_raw(url, json!({"jsonrpc":"2.0","method":"debug_traceTransaction","params":[known_tx_hash, {"tracer":"callTracer"}],"id":1}))
.await.is_ok()
} Try / catch
match client.probe_call_trace().await {
Ok(()) => Ok(()),
Err(e) if e.to_string().contains("request failed") => {
log::warn!("callTracer probe failed; check node reachability and debug namespace: {e}");
Err(anyhow!("tracing endpoint unusable: {e}"))
}
Err(e) => Err(e),
} Prevention
- Enable the debug/trace namespace in node flags (--http.api eth,net,debug)
- Verify reachability, DNS, and TLS with a simple eth_chainId curl before probing
- Use dedicated trace-enabled nodes for debug_* workloads; don't probe disabled providers
- Capture and log the wrapped source error to distinguish timeouts, refusals, and HTTP 5xx
When it happens
Trigger: Any non-redirect transport failure during the probe: connection refused/timeout, DNS failure, TLS errors, HTTP 5xx from the node, or the client error message not containing "redirect response rejected".
Common situations: Node down or unreachable (firewall, wrong host/port); `debug_*` namespace disabled causing error responses; timeouts on slow nodes; TLS certificate problems.
Understand the failure class
Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.
Related errors
- debug_traceTransaction returned no result
- Failed to parse debug_traceTransaction response
- eth_call RPC error {code}
- eth_call RPC error {}
- debug_traceTransaction RPC error {code}
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/2c2cb8dcd13437f1.
Report an issue: GitHub.