Skip to content

[Bug]: mavis mcp call on HTTP/Streamable-HTTP servers fails forever after upstream restart — no auto-reinit, no CLI recovery #109

Closed as not planned

Description

@tntstupido

Version / 版本号

v3.0.47

Platform / 平台

Windows

OS version / 系统版本

Windows 11 Pro 24H2 (build 26200)

Issue area / 问题类型

Other

Upload ID / 日志上传 ID

489342108636860422

What happened? / 问题描述

mavis mcp call permanently fails on HTTP/Streamable-HTTP MCP servers after the upstream restarts. The Mavis client caches the Mcp-Session-Id and never re-runs initialize — there is no CLI verb, no daemon endpoint, and no documented workaround. The only bypass is registering the same endpoint under a different URL form (localhost vs 127.0.0.1).

Steps to reproduce / 复现步骤

  1. Add any HTTP MCP server. In my case the upstream is the bundled Unreal Engine 5.8 ModelContextProtocol plugin at http://127.0.0.1:8000/mcp:
    mavis mcp add unreal-mcp '{"type":"http","url":"http://127.0.0.1:8000/mcp"}'
  2. Confirm a call works so the session is established:
    echo '{}' | mavis mcp call unreal-mcp list_toolsets --stdin
  3. Restart the upstream MCP server. In my case: close and reopen the Unreal Engine 5.8 editor (or any action that invalidates the upstream's session state — Live Coding hot-reload, plugin enable, port change).
  4. Repeat the same call:
    echo '{}' | mavis mcp call unreal-mcp list_toolsets --stdin
  5. Result (forever): "Error: MCP tool call failed: Streamable HTTP error: Unknown session id '' for 'tools/call'; client should reinitialize". Every subsequent call returns the same dead-session error.
  6. mavis mcp sync returns SYNC_ERROR for the affected server. mavis mcp disable unreal-mcp && mavis mcp add unreal-mcp '{...same URL}' does NOT recover (the cache key is the URL, not the server name).
  7. Workaround that does work: re-register under a different URL form, e.g. http://localhost:8000/mcp instead of http://127.0.0.1:8000/mcp. The daemon allocates a fresh session slot and calls succeed.

Expected behavior / 预期行为

When the upstream MCP server returns "Unknown session id … client should reinitialize", the Mavis client should drop the cached id and re-issue initialize, then retry the original call once. Per the MCP Streamable-HTTP spec this is the required behavior. Failing that, an explicit mavis mcp session-reset <server> (or equivalent) CLI verb would let the operator recover without URL gymnastics.

Actual behavior / 实际行为

The daemon caches Mcp-Session-Id indefinitely and reuses it on every call. Every call after an upstream restart returns the same dead-session error with no auto recovery. mavis mcp sync does not recover the session. The mcp-cli skill body is silent on this failure mode. Recovery today requires editing the registered URL (different host form or different port) — fragile, undocumented, and unsustainable for any integration whose upstream routinely restarts.

Affected integrations include the Unreal Engine 5.8 MCP plugin (just shipped 2026-06-17), Blender MCP servers (auto-restart on file save), and any stdio→http bridge like mcp-remote whose session TTL expires.

Version: mavis v3.0.47 (Windows 11 Pro 24H2 / build 26200). Upload ID: 489342108636860422.

Logs or crash report / 日志或崩溃信息

$ echo '{}' | mavis mcp call unreal-mcp list_toolsets --stdin
Error: MCP tool call failed: Streamable HTTP error: Error POSTing to endpoint: {
  "jsonrpc": "2.0",
  "id": 4,
  "error": {
    "code": -32600,
    "message": "Unknown session id 'a99e026f4569bc66d69110b80deb5046' for 'tools/call'; client should reinitialize"
  }
}
code: 50205 (mcp error)

# Reproduced verbatim each call after upstream MCP server restart.
# 'mavis mcp disable <srv> && mavis mcp add <srv> <same url>' does NOT recover.
# Recovered only by registering same endpoint under a different URL form
# (localhost vs 127.0.0.1); daemon appears to key session cache by URL.

Screenshots / 截图

No response

Before submitting / 提交前确认

  • I have searched existing issues.
  • I am using the latest version available to me.
  • I have removed sensitive information from logs/screenshots.

Activity

  1. iamagenius00 commented on Jul 5, 2026

    @iamagenius00
    Collaborator

    Thanks for the detailed write-up and clear repro steps. We’ve tracked this down to stale MCP session handling after an upstream HTTP server restarts. We’re working on a MiniMax Code update that should recover from this automatically, and we’ll follow up here once the fix is available.

  2. tntstupido commented on Jul 6, 2026

    @tntstupido
    Author

    Thanks for jumping on this so fast — really appreciate the team digging in. And honestly, the report only came out that clean because Mavis (https://minimax.com/) helped me structure the repro steps and isolate the failure mode. Looking forward to the update.

  3. added
    desktopMiniMax Code desktop app
    and removed
    desktopMiniMax Code desktop app
    on Sep 19, 2026
  4. hetaoBackend commented on Oct 19, 2026

    @hetaoBackend
    Collaborator

    Closing as part of a backlog cleanup: this issue was filed more than a month ago against an older release, and the codebase has changed substantially since then. If it still reproduces on the latest version, please open a new issue with the current version and reproduction steps. Thank you for the report!

    批量清理积压:该 issue 创建已超过一个月,针对的是较旧版本,代码已有较大变化。如果在最新版本上仍能复现,欢迎附上当前版本号和复现步骤重新提交 issue。感谢反馈!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingdesktopMiniMax Code desktop appneeds-triageAwaiting maintainer assessment

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions