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:
@@ -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);
|
||||
|
||||
|
||||
Reference in New Issue
Block a user