stop wallet chain reads hanging on an unreachable esplora

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 <noreply@anthropic.com>
This commit is contained in:
2026-07-31 15:12:41 +00:00
co-authored by Claude Opus 5
parent 2647510965
commit bed8854206
+6
View File
@@ -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);