From bed885420635b8b6236b7559db4fa4dfbbf1125c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Padez?= Date: Fri, 31 Jul 2026 15:12:41 +0000 Subject: [PATCH] stop wallet chain reads hanging on an unreachable esplora MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A wallet whose Esplora endpoint was slow or down rendered as a wallet with no data at all, rather than as an error. The cause was a timeout inversion: Bun.serve's default idleTimeout is 10s, which is shorter than the Esplora client's own 20s per-request timeout. Bun killed the response before the scan could either finish or report why it had not, so the failure never reached the handler that would have surfaced it. The ceiling has to sit above the whole gap-limit walk, not one request — a scan is many sequential rounds of address queries. Raised to 255s, Bun's maximum, which is what every other sidecar already uses. Co-Authored-By: Claude Opus 5 --- src/servers/sidecar/wallet/index.ts | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/servers/sidecar/wallet/index.ts b/src/servers/sidecar/wallet/index.ts index 471afa36..5fd3f3d0 100644 --- a/src/servers/sidecar/wallet/index.ts +++ b/src/servers/sidecar/wallet/index.ts @@ -94,6 +94,12 @@ const server = Bun.serve({ hostname: '127.0.0.1', // Wallet payloads are small — PSBTs and invoices, never file uploads. A tight cap is free hardening. maxRequestBodySize: 1 * 1024 * 1024, + // Bun's default is 10s, which is SHORTER than the Esplora client's own 20s per-request timeout. That + // inversion is why a slow or unreachable upstream showed up as a wallet with no data at all rather than + // as an error: Bun killed the response before the scan could either finish or report why it hadn't. + // A gap-limit scan is many sequential rounds, so the ceiling has to sit above the whole walk, not one + // request. Bun caps this at 255s; every other sidecar already uses that. + idleTimeout: 255, async fetch(req) { const url = new URL(req.url);