Skip to content

Fix MCP session-mode negotiation logged at error level, recurring false error signal - #18

Open
polylane[bot] wants to merge 1 commit into
mainfrom
polylane/autofix/fe3e0qicd2tc
Open

Fix MCP session-mode negotiation logged at error level, recurring false error signal#18
polylane[bot] wants to merge 1 commit into
mainfrom
polylane/autofix/fe3e0qicd2tc

Conversation

@polylane

@polylane polylane Bot commented Sep 7, 2026

Copy link
Copy Markdown

Fixes: MCP session-mode negotiation logged at error level, recurring false error signal

The executor's MCP session-mode negotiation snapshot is logged through console.error even though it is informational state — client capabilities, elicitation mode, and the resume flag recorded at the end of a successful session negotiation. This has made monitoring treat ordinary session traffic as errors, producing a false high-severity incident on Aug 31 and re-flagging the same line again now.

What caused this

Affected: Durable Object executor-cloudflare_McpSessionDO · Cloudflare account fdd120ce6acd80e0c9812d5fbc910db0 · DO Requests at 0 · 1 dependent, ~7% of nearby traffic

DO Requests

ERROR log volume

Log lines that fired the check

Level Count Log line Last occurrence
WARN 16× [executor] VITE_PUBLIC_SITE_URL is not set and no platform origin was detected; falling back to the per-request origin. OAuth redirects, MCP metadata, and connect links will use this — set VITE_PUBLIC_SITE_URL to your public origin (e.g. https://your-instance.example.com). {"level":"warn","message":"[executor] VITE_PUBLIC_SITE_URL is not set and no platform origin was detected; falling back to the per-request origin. OAuth redirects, MCP metadata, and connect links will use this — set VITE_PUBLIC_SITE_URL to your public origin (e.g. https://your-instance.example.com)."} Sep 7, 2026, 04:40 UTC
ERROR 12× [executor] MCP session mode {"clientCapabilities":null,"elicitationSupport":{"form":false,"url":false},"elicitationMode":"model","resumeEnabled":true} {"level":"error","message":"[executor] MCP session mode {\"clientCapabilities\":null,\"elicitationSupport\":{\"form\":false,\"url\":false},\"elicitationMode\":\"model\",\"resumeEnabled\":true}"} Sep 7, 2026, 04:35 UTC
ERROR [executor] MCP session mode {"clientCapabilities":{"elicitation":{"form":{}},"roots":{"listChanged":true}},"elicitationSupport":{"form":true,"url":false},"elicitationMode":"model","resumeEnabled":true} {"level":"error","message":"[executor] MCP session mode {\"clientCapabilities\":{\"elicitation\":{\"form\":{}},\"roots\":{\"listChanged\":true}},\"elicitationSupport\":{\"form\":true,\"url\":false},\"elicitationMode\":\"model\",\"resumeEnabled\":true}"} Sep 7, 2026, 04:35 UTC

What changed

  • packages/hosts/mcp/src/tool-server.ts: syncToolAvailability now emits its [executor] MCP session mode negotiation snapshot with console.info instead of console.error; the payload is unchanged.

Why it's safe

  • Payload and call-site logic are untouched: only the console method changes, so no behavior, data, or consumer contract changes.
  • Error paths are unaffected: actual failures (internal error; reference = ... and thrown exceptions) are emitted elsewhere and remain error-level, so real faults stay distinguishable from session negotiation.
  • The snapshot remains visible: the worker's observability config persists info-level logs at head sampling rate 1, so the session-mode data monitoring relies on is not lost.
  • Single-line change with scoped validation green (typecheck, lint, 216/216 tests), no schema, config, or dependency changes.

Validation

  • pnpm --filter @airbooks/mcp typecheck: 0 errors
  • pnpm --filter @airbooks/mcp lint (oxlint, changed file): 0 warnings
  • pnpm --filter @airbooks/mcp test: 216/216 pass
Root cause and scoping notes

Root cause

Cloudflare Workers observability flagged 55 error-level events over 24h, all the [executor] MCP session mode {...} signature from the executor worker. The emitting call site is syncToolAvailability in packages/hosts/mcp/src/tool-server.ts:2324, which serializes the negotiated session state after a successful (re)negotiation — it is not an error path. Corroboration that nothing failed: workersInvocationsAdaptive shows 99 requests and 0 errors over the same window, and traces show 0 errors/faults. The same signature produced confirmed issue iss_055aef9a9001b0v7jafym0cy (severity high) on 2026-08-31, so this mislabel is the root cause of recurring false incidents. Emitting the snapshot at info level keeps the visibility (the worker persists info logs at full head sampling) while letting genuine failures keep their error level.

Outcome after fix

A client connects and the server negotiates session mode. syncToolAvailability completes and emits the same [executor] MCP session mode JSON snapshot, now at info level. Workers observability routes it to info logs rather than error logs, so the "mcp-session-error" content review no longer matches informational session traffic, and the false error signal stops. A genuine failure later produces internal error; reference = ... or an exception, which still lands at error level and is still flagged. The session-mode state that previous incidents relied on remains queryable in the info-level logs.

1 file changed (+1/-1)
  • packages/hosts/mcp/src/tool-server.ts: modified, +1/-1

view-autofix view-investigation view-issue


Generated by Polylane.

@polylane polylane Bot added polylane severity:low Polylane autofix severity: low labels Sep 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

polylane severity:low Polylane autofix severity: low

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants