mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 22:56:55 +01:00
4c225c4ac3
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> |
||
|---|---|---|
| .. | ||
| machine | ||
| templates | ||
| bc-mcp-bridge.js | ||
| curabis-standard.agent.md | ||
| support-users-onboarded.md | ||
| sync-bcquality-knowledge.ps1 | ||