## Summary `POST /api/v4/orbit/mcp` rejects any JSON-RPC notification that has no handler with **HTTP 404** `-32601 Method not found`. Since Duo CLI started cancelling tool calls (likely gitlab-org/editor-extensions/gitlab-lsp!4197, merged 2026-09-25), every interactive turn that pauses for approval sends `notifications/cancelled`. The 404 makes Duo CLI mark Orbit as failed. **Interactive GitLab Duo CLI therefore gets one Orbit Remote call per session.** **Fix verified.** We put a local relay between Duo CLI and the endpoint, and changed only how it answers `notifications/cancelled`: | | Relay answers the cancel with 202 (proposed fix) | Relay forwards the cancel to GitLab | |---|---|---| | Orbit Remote calls that ran | **5** | **1** | | Approval pauses survived | **4 of 4** | 0 (server marked failed 2 ms after GitLab's 404) | | Outcome | Answered from the graph | "Tool not found" | Everything else was the same in both runs: client, config, question, transport and token. It reproduced in all 3 interactive sessions we ran. Headless `glab duo cli run` never pauses, sends no cancels, and works. This is a sibling of #628350 (a 204 instead of 202 for `notifications/initialized`), but **fixing #628350 alone won't fix it**. A notification with no handler is rejected before any 202/204 response is chosen. ## Impact - **GitLab's own agent is the one that fails.** Orbit is positioned as working "over MCP with any agent you're using". Duo CLI with Orbit Remote breaks on its second call. - **It fails silently.** In one session the user approved `invoke_command`, the call never ran, and the agent answered through 4 shell commands (REST via `glab`). Nothing on screen said Orbit had dropped, so the user believes the answer came from the graph. - **Or it gives wrong advice.** In another session it reported "Tool not found" and told the user to "ask your GitLab admin to register the orbit-remote MCP server". The server was registered and working. - **The fix is small:** one file plus specs, and the relay test shows it works. ## Steps to reproduce Two requests against GitLab.com, with any token that has `mcp_orbit`, `mcp` or `read_api` scope, on a user with Orbit enabled: ```shell H=(-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream") U=https://gitlab.com/api/v4/orbit/mcp curl -s -w " -> HTTP %{http_code}\n" "${H[@]}" $U \ -d '{"jsonrpc":"2.0","method":"notifications/initialized"}' # -> HTTP 204 (should be 202, tracked in #628350) curl -s -w " -> HTTP %{http_code}\n" "${H[@]}" $U \ -d '{"jsonrpc":"2.0","method":"notifications/cancelled","params":{"requestId":2,"reason":"test"}}' # {"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found","data":{"method":"notifications/cancelled"}},"id":null} -> HTTP 404 ``` **End to end in GitLab Duo CLI 9.26.0:** 1. Add `"orbit-remote": {"type":"http","url":"https://gitlab.com/api/v4/orbit/mcp"}` under `mcpServers` in `~/.gitlab/duo/mcp.json`, then complete the OAuth sign-in. 2. Run `glab duo cli` (interactive) and ask: *"Use only the orbit-remote graph tools. How many merge requests does this project have, and how many pipelines have failed?"* 3. Approve `list_commands`. It succeeds. 4. As the next approval prompt appears, `orbit-remote` fails. Approving `invoke_command` doesn't make it run. **Control:** the same question headless makes 5 Orbit Remote calls, with no cancels and no failures: ```shell glab duo cli run --goal "Use only the orbit-remote graph tools. How many merge requests does this project have, and how many pipelines have failed?" 2> duo-run.log grep -o 'Running MCP tool: "[^"]*"' duo-run.log | sort | uniq -c # 4 Running MCP tool: "mcp__orbit-remote__invoke_command" # 1 Running MCP tool: "mcp__orbit-remote__list_commands" ``` ## Duo CLI log (interactive session) ```plaintext 20:05:46 Running MCP tool: "mcp__orbit-remote__list_commands" 20:05:51 request to https://gitlab.com/api/v4/orbit/mcp returned HTTP 404 Streamable HTTP error: Error POSTing to endpoint: {"jsonrpc":"2.0","error":{"code":-32601, "message":"Method not found","data":{"method":"notifications/cancelled"}},"id":null} 20:05:51 [MCP Manager] orbit-remote: Failed to connect to MCP server: orbit-remote. 20:05:51 Workflow turn ended: awaiting_tool_approval 20:05:52 handleChoiceSubmit: tool=mcp__orbit-remote__invoke_command approved=true (no "Running MCP tool" line for invoke_command follows) 20:06:10 PreToolUse: tool=run_command <- 4 shell commands follow; the agent answers from REST ``` The relay log shows what the cancel carries. It always refers to the call that has just returned 200: `notifications/cancelled params={"requestId": 2, "reason": "AbortError: The operation was aborted."}` ## Cause `ee/lib/api/orbit/mcp.rb` (master at `902c553b0e45`) routes messages through a fixed table: ```ruby JSONRPC_METHOD_HANDLERS = { 'initialize' => McpHandlers::InitializeRequest, 'notifications/initialized' => McpHandlers::InitializedNotification, 'tools/list' => McpHandlers::ListTools, 'tools/call' => McpHandlers::CallTool }.freeze ``` Any other method goes to `method_not_found!`, which renders a JSON-RPC error with **HTTP 404**. For notifications, that breaks the spec in two ways: 1. **Notifications must get 202.** The [Streamable HTTP transport](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#sending-messages-to-the-server) says: *"If the input is a JSON-RPC response or notification: If the server accepts the input, the server MUST return HTTP status code 202 Accepted with no body."* The [cancellation spec](https://modelcontextprotocol.io/specification/2025-06-18/basic/utilities/cancellation#behavior-requirements) lets receivers *"ignore cancellation notifications if… processing has already completed"*, so a 202 no-op is compliant. 2. **404 means "session terminated" in this transport** (*"after which it MUST respond to requests containing that session ID with HTTP 404 Not Found"*), and clients treat it as fatal. Even for real requests to unknown methods, a `-32601` in a 200 or 400 response would be safer. ## Proposed fix - Treat any message with no `id` as a notification: accept it and return **202 with no body**, whether or not a handler exists. That also covers #628350. - Return JSON-RPC errors for unknown **requests** with a non-404 status. - Add specs to `ee/spec/requests/api/orbit/mcp_spec.rb` for `notifications/cancelled` and an unknown notification. ## Related - **#628350**, open: the same endpoint answers `notifications/initialized` with 204 instead of 202, which breaks the Bifrost MCP gateway. A 29 Sep comment there also reports `ping` returning `-32601`, the same missing handling showing up for a different message. - **!254461** was expected to carry the #628350 fix, but it was closed without merging on 2026-09-17. - **#627825** is the parent MCP spec-conformance work. - **gitlab-org/editor-extensions/gitlab-lsp!4197** (merged 2026-09-25) made Duo CLI MCP tool calls interruptible and passed the turn's abort signal into them. That's the likely reason Duo CLI started sending these cancels. We didn't test an older CLI version. - **`lib/api/mcp/base.rb`** (the main `/api/v4/mcp` endpoint) has the same fall-through to `method_not_found!` with 404, so it probably behaves the same way. We couldn't verify it live, because our token isn't allowed on that endpoint. ## Client side, to raise separately with GitLab Duo CLI This issue covers the server, which is where the spec is broken. The client makes it worse in four ways: - **It cancels requests that have already completed.** The spec says cancels *"MUST only reference requests that… are believed to still be in-progress"*. - **It drops the whole server over one failed notification.** - **The fallback is silent.** An approved call that never runs should be visible to the user. - **`approvedTools` in `mcp.json` is ignored.** It's parsed (`preapproved_tools=3`), but every MCP call still pauses for approval. With pre-approval working, this bug would rarely trigger. ## Environment | | | |---|---| | GitLab | GitLab.com, `serverInfo.version` `19.5.0-pre` ("GitLab Orbit MCP Server") | | Client | GitLab Duo CLI 9.26.0 through `glab` 1.120.0, macOS arm64 | | Namespace | Ultimate; the project is fully indexed per `orbit graph-status` | | Observed | 2026-09-30. Interactive 3 of 3 sessions; relay A/B once each; headless control clean | | Relay runs | The relay added a `glab` token instead of Duo's OAuth, the same in both A/B runs. The relay script and its logs are available on request |