Neither of the bridge's two "clear sessionId and reinitialize" paths ever
told BC the old session was actually done - they just drop the local
sessionId variable and let a fresh session get issued on the next call.
The MCP Streamable HTTP transport spec defines an explicit way to end a
session: an HTTP DELETE to the endpoint carrying the session's
Mcp-Session-Id. The bridge has never called it.
Trying this as a candidate fix for the recurring Internal_CompanyNotFound
pattern documented in bc-mcp-company-header-must-match-exact-company-name.md:
a client-side session reset (clear sessionId + reinitialize) does NOT clear
the error, but a manual save on the BC-side MCP Server Configuration record
does. If BC's server-side session state is what's actually stuck, an
explicit close might do the same job the manual config-save has been doing
by accident.
Committed before live-testing (not after) specifically so it survives the
next sync-bcquality-knowledge.ps1 run instead of being silently overwritten
from the old source - this is a durability commit, not a confirmed-fix
commit. Best-effort and silent on failure: if BC responds 404/405 (DELETE
not implemented), that's evidence for the MS support escalation, not a bug
here. Update this commit's status (confirmed working / confirmed no effect
/ reverted) once tested against a live recurrence.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New follow-up section, distinct from the 2026-08-03 "ruled out" static
verification (Aktiv/Standard confirmed on, unchanged). This is about the
save/toggle *action* on CURABIS_DEV's MCP Server Configuration page, not
its resting state - not previously tested.
Observed 2026-08-07 (MID): Internal_CompanyNotFound recurred. VS Code
restart + retry failed (consistent with the already-falsified restart
theory). Toggling the Standard field on CURABIS_DEV and saving, then
retrying, worked immediately. MID reports having seen this same pattern -
restart-retry fails, config-touch-retry succeeds - on prior occasions.
Framed explicitly as a candidate, not a confirmed fix: n>=2 informal
observations, toggle direction untested (MID's own read is that direction
is probably irrelevant, pointing at the save/republish action busting a
server-side cache rather than at the field's value), and no baseline
established against the error's already-documented intermittency. Does
not override the Microsoft-support-escalation guidance - if anything it's
supporting evidence for that escalation, since a CURABIS-side config touch
masking a BC-side symptom points at BC's MCP session/cache layer.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
PR #36 (merge dd4dc4e) merged 'stable' into the fix branch before merging
back, and that intermediate merge silently resolved the conflict in favor
of stable's older content instead of the fix branch's. Result: 8e85976's
retraction (drop the falsified "restart Claude Code" theory, confirm
MS-support escalation) is reachable in history but never actually landed
in stable's tree - the blob at 3142ce8 was byte-identical to 73e5a01
(pre-fix). Discovered live while troubleshooting a real Internal_CompanyNotFound
recurrence on 2026-08-07: the mirrored knowledge file still told the
developer to restart Claude Code, the exact theory 8e85976 falsified.
Restores the file to 8e85976's blob content directly - no merge needed,
just the correct final state.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two fixes bundled together, both diagnosed from a live BC MCP failure in
a Jernpladsen (Project Management 365) session:
- 2026-08-05 (previously drafted, never committed): BC rejects a
non-initialize request with a stale/absent Mcp-Session-Id with "A new
session can only be created by an initialize request." The prior retry
just cleared sessionId and resent the same message with no header,
reproducing the identical error. Now replays the client's cached
initialize message first to obtain a fresh session, then retries.
This also fixes dispatchCreateComment's per-chunk fresh-session reset,
which was hitting exactly this failure on every chunk of a >250-char
Task Comment.
- 2026-08-07: the reactive fix above only self-heals after BC has
already rejected a request. A client that opens a fresh session per
call (e.g. a Power Automate flow) never hits staleness at all, which
is why that pattern reads as more reliable than our long-lived
interactive bridge process. Added a proactive refresh: if the cached
session has been idle past a heuristic threshold, re-initialize
before attempting the call instead of waiting for the rejection.
Promotes rules that are already published in community/ to custom/knowledge/,
so they load at every session start instead of only on keyword relevance.
Each file carries extends: pointing back to its community source.
Passed Immanuel's four-test Categorical Imperative validation on 2026-08-07.
