Michael Dieringer 0563887aea bc-mcp-bridge: timeout + one-retry-with-fresh-session self-heal ... Neither fetch() call had a timeout, and the BC session (Mcp-Session-Id) plus the underlying HTTP connection were reused for the bridge process's entire lifetime with no proactive refresh. A long-running Claude Code session with gaps between calls can leave either stale. Observed today: a 30-minute hang on one call (no timeout meant it never failed on its own), and separately an "Internal_CompanyNotFound" on two machines that likely wasn't a real company problem but a dead session -- Michael noticed the pattern independently: Summatim's frequent quick calls never have this issue, longer sessions with gaps do. Added REQUEST_TIMEOUT_MS (30s) via AbortSignal.timeout on both fetch calls, and wrapped forward() to retry once with sessionId cleared on any failure -- self-heals a stale session/connection without the developer noticing. Tested end to end: full initialize + tools/call succeeds normally (no retry needed), and a forced-failure path correctly retries once then surfaces the real error if it persists.		2026-08-05 14:05:42 +02:00
..
machine	Deploy a shared MCP-tool permissions allowlist; detect legacy .claude/settings.json	2026-08-04 07:31:46 +02:00
templates	Fix all 6 confirmed findings from today's gap audit	2026-08-03 14:12:05 +02:00
bc-mcp-bridge.js	bc-mcp-bridge: timeout + one-retry-with-fresh-session self-heal	2026-08-05 14:05:42 +02:00
curabis-standard.agent.md	Add Node.js runtime prerequisite check before machine setup Step 3	2026-08-04 12:41:09 +02:00
support-users-onboarded.md	Fix all 6 confirmed findings from today's gap audit	2026-08-03 14:12:05 +02:00
sync-bcquality-knowledge.ps1	Deploy a shared MCP-tool permissions allowlist; detect legacy .claude/settings.json	2026-08-04 07:31:46 +02:00