From 84da3b149b7ca0597d68b3412b0eba150549efb4 Mon Sep 17 00:00:00 2001 From: mptyl Date: Sat, 18 Jul 2026 11:48:05 +0200 Subject: [PATCH] fix(backend): log the real bootstrap failure cause server-side MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Session bootstrap swallowed configure/retrieval errors and surfaced only the generic BOOTSTRAP_FAILURE_MESSAGE, so an operator could not tell why a session "didn't start" — e.g. `tht search pack` failing because the DWH/vector host is unresolvable behind a dropped VPN. Log the underlying error to the backend console; the client-facing message stays generic. Co-Authored-By: Claude Opus 4.8 --- backend/src/routes/sessions.ts | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/backend/src/routes/sessions.ts b/backend/src/routes/sessions.ts index 7f1299a8..0602cf1f 100644 --- a/backend/src/routes/sessions.ts +++ b/backend/src/routes/sessions.ts @@ -142,7 +142,11 @@ export function sessionRoutes( info(id, "Starting model"); if (d.mgr.get(id) !== rt) return; start(); - } catch { + } catch (error) { + // The client only ever sees the generic BOOTSTRAP_FAILURE_MESSAGE; log the real + // cause server-side so failures (e.g. an unreachable DWH/vector host behind a + // dropped VPN) are diagnosable from the backend console instead of silent. + console.error(`[pi:${id}] bootstrap failed:`, error instanceof Error ? error.message : error); void withSessionLifecycle(id, async () => { // A bootstrap continuation can settle after Close/Delete or after a replacement was // installed. Claim only the runtime identity that actually failed; holding the same