From 3ab7fb521a78d607b99b6b87f6dbb355d8b58776 Mon Sep 17 00:00:00 2001 From: archipelago Date: Mon, 20 Jul 2026 14:03:33 -0400 Subject: [PATCH] fix(rpc): log the full error chain, not just the outermost context RPC failures logged only the top-level anyhow context, so a peer-files failure produced exactly "RPC error on content.browse-peer: Failed to connect to peer" with the real cause discarded. That made it impossible to tell a dead peer from a slow Tor circuit from a FIPS resolve failure without reproducing by hand. Switch the log line to `{:#}` so the whole context chain is rendered. The client-facing message still uses `{}` through sanitize_error_message, so no internal detail is leaked to callers. Co-Authored-By: Claude Opus 4.8 (1M context) --- core/archipelago/src/api/rpc/mod.rs | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/core/archipelago/src/api/rpc/mod.rs b/core/archipelago/src/api/rpc/mod.rs index c86c564f..0ec4b4b2 100644 --- a/core/archipelago/src/api/rpc/mod.rs +++ b/core/archipelago/src/api/rpc/mod.rs @@ -438,7 +438,13 @@ impl RpcHandler { } } Err(e) => { - error!("RPC error on {}: {}", rpc_req.method, e); + // `{:#}` renders the whole anyhow context chain. Logging only the + // outermost context threw away the actual cause: a peer-files + // failure logged just "Failed to connect to peer", with the real + // error (Tor SOCKS failure, FIPS resolve, timeout) discarded — so + // the logs couldn't distinguish a dead peer from a slow circuit. + // The client-facing message below stays `{}` so internals aren't leaked. + error!("RPC error on {}: {:#}", rpc_req.method, e); let user_message = sanitize_error_message(&e.to_string()); RpcResponse { result: None,