chore(deps): update fastmcp requirement from <4.0.0,>=3.0.0 to >=3.0.0,<5.0.0 - #1119
chore(deps): update fastmcp requirement from <4.0.0,>=3.0.0 to >=3.0.0,<5.0.0#1119dependabot[bot] wants to merge 1 commit into
Conversation
dependabot
Bot
added
Dependencies
python:uv
burtenshaw
added
enhancement
Cursor
|
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Alignment Review Report
TL;DR: This one-line bump widens fastmcp to >=3.0.0,<5.0.0, which resolves to fastmcp 4.0.3 — a major release (MCP Python SDK v2, httpx→httpx2, pydantic 2.13, fastapi 0.141). I verified locally that fastmcp 4.x regresses a core OpenEnv feature — MCP session-state persistence — breaking 2 of the 3 tests in TestMCPSessionTransportPersistence that pass on fastmcp 3.4.7. Recommendation: do not merge as-is; either hold the <4.0.0 cap or migrate the MCP layer first (details below).
Automated Checks
- Lint: PASS for this diff.
ruff check src/ tests/passes. The format hook flags only pre-existing drift underenvs/**(and README code-fences it reformats as a side effect) — nothing insrc//tests/. This PR touches no Python, so lint is unaffected by the change. - Debug code: FOUND but all pre-existing (
print(...)/TODOinsrc/…) and unrelated to this diff (no.pyfiles changed).
Open RFCs Context
- All RFCs are In Review (010 is Draft). Directly relevant: RFC 003 — MCP Support (
@Darktex,@pankit-eng). MCP is the sole agent-facing interface (PRINCIPLES.md “MCP as universal standard”; INVARIANTS.md “Dual API boundary”), so the MCP-engine major version is alignment-sensitive.
Tier 1: Fixes Required
-
pyproject.toml:32— Widening to<5.0.0resolves to fastmcp 4.0.3, which breaks core tests (functional regression, not style):tests/core/test_production_mode_routes.py::TestMCPSessionTransportPersistence::test_http_session_mcp_state_persists_across_callstests/core/test_production_mode_routes.py::TestMCPSessionTransportPersistence::test_websocket_mcp_state_persists_across_calls
Evidence (same tree, only fastmcp version swapped):
fastmcp TestMCPSessionTransportPersistence3.4.7 3 passed 4.0.3 2 failed ( inc_counterreturns1on the 2nd call instead of2— session state not retained)Root cause: FastMCP 4's
Clientnow defaults tomode="auto"(the sessionless modern protocol era). OpenEnv'sMCPEnvironment.mcp_session()(src/openenv/core/env_server/mcp_environment.py) depends on a persistent FastMCPClientsession forctx.set_state/ctx.get_state. The official 3→4 upgrade guide states that code relying on session state must pinClient(mode="legacy").Also observed:
FastMCPDeprecationWarningatsrc/openenv/core/env_server/mcp_environment.py:111—Tool.inputSchemawas renamed to.input_schemaunder SDK v2 (bridged with a warning in 4.x; will hard-break in 5.x).Note: there is no mechanical one-line fix inside this diff — resolving it is a design decision (see Tier 2 / Recommendation).
Tier 2: Alignment Discussion
Principle Conflicts
ALIGNMENT FLAG: Allowing fastmcp 4.x silently changes agent↔environment interaction semantics (loss of MCP session state)
- Principle/RFC at stake: RFC 003 (MCP as universal standard); PRINCIPLES.md “Minimize lifecycle deltas” + “Production-readiness from day one”; INVARIANTS.md “Dual API boundary”.
- The concern: MCP is the only agent-facing interface. Losing session persistence across MCP calls changes runtime behavior for every stateful MCP env (per-episode counters/context), and it would land silently through a dependency range rather than a reviewed code change — a lifecycle-delta / production-readiness risk.
- Suggested reviewer:
@Darktex(git blame: authored the MCP rows in PRINCIPLES.md/INVARIANTS.md and RFC 003) and@pankit-eng(RFC 003 co-author); also loop in the owner of the MCP session adapter + persistence tests (git blame authorswappy).
RFC Conflicts
- No RFC proposes adopting MCP SDK v2 / fastmcp 4.x. Because RFC 003 is In Review and defines MCP as the universal agent interface, moving to a new MCP-engine major version is exactly the kind of change that should be reconciled with (or noted in) RFC 003 rather than arriving via an unpinned range.
Recommendation
Two viable paths:
- Hold the cap at
fastmcp>=3.0.0,<4.0.0until a deliberate migration (close this Dependabot PR or convert it to a tracking issue). - Migrate the MCP layer first, then widen: pin
Client(mode="legacy")(or otherwise restore session persistence under SDK v2), switchTool.inputSchema→.input_schema, move the twoexcept httpx.…handlers (envs/calendar_env/server/handlers/tool_handlers.py,envs/opencode_env/sandbox/hf.py) tohttpx2, and re-run the MCP suite green.
Heads-up: several env pyproject.tomls already declare fastmcp>=2.0.0/>=3.0.0 with no upper bound, so they can independently resolve 4.x today — a coordinated migration is worthwhile regardless of this PR.
Summary
- 1 blocking issue — fastmcp 4.x regresses MCP session persistence (2 failing core tests); decision needed: hold cap vs. migrate.
- 2 alignment points for human review — MCP semantics change via a dependency range; reconcile with RFC 003.
- 0 unrelated Tier-1 lint/debug issues introduced by this diff.
Sent by Cursor Automation: Pre-review
| "websockets>=15.0.1", | ||
| # MCP support | ||
| "fastmcp>=3.0.0,<4.0.0", | ||
| "fastmcp>=3.0.0,<5.0.0", |
There was a problem hiding this comment.
<5.0.0 resolves to fastmcp 4.0.3 (MCP SDK v2 / httpx2). I verified this breaks MCP session-state persistence: TestMCPSessionTransportPersistence is 3 passed on fastmcp 3.4.7 but 2 failed on 4.0.3 (ctx.set_state/ctx.get_state no longer persist across calls).
Root cause: FastMCP 4's Client defaults to sessionless mode="auto"; MCPEnvironment.mcp_session() relies on a persistent session and would need Client(mode="legacy") per the 3→4 upgrade guide.
Suggest keeping <4.0.0 until the MCP layer is migrated (also: Tool.inputSchema→.input_schema, and httpx→httpx2).
There was a problem hiding this comment.
Blocking at head fa8d5eb4f7576835b480840586cde1fc82904f0b: allowing FastMCP 4.0.3 breaks MCP session-state persistence in both supported test matrices (test_http_session_mcp_state_persists_across_calls and test_websocket_mcp_state_persists_across_calls). Keep the <4.0.0 cap for this release. A separate migration should explicitly preserve legacy session semantics, update the renamed tool schema API, and validate the MCP transport before widening the major-version range.
Sent by Cursor Automation: Release
fa8d5eb to
37fb4ed
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 37fb4ed. Configure here.
| "websockets>=15.0.1", | ||
| # MCP support | ||
| "fastmcp>=3.0.0,<4.0.0", | ||
| "fastmcp>=3.0.0,<5.0.0", |
There was a problem hiding this comment.
FastMCP 4 breaks MCP integration
High Severity
Widening fastmcp to <5.0.0 lets installs pick FastMCP 4, which uses MCP SDK v2 and a sessionless protocol. Tool listing still reads inputSchema and silently substitutes {} when that attribute is absent, so agents see tools with empty schemas. Client is also created without mode="legacy", so the held-session path no longer preserves FastMCP ctx state across HTTP calls.
Reviewed by Cursor Bugbot for commit 37fb4ed. Configure here.
37fb4ed to
b0894c8
Compare
Updates the requirements on [fastmcp](https://github.com/PrefectHQ/fastmcp) to permit the latest version. - [Release notes](https://github.com/PrefectHQ/fastmcp/releases) - [Changelog](https://github.com/PrefectHQ/fastmcp/blob/main/docs/changelog.mdx) - [Commits](PrefectHQ/fastmcp@v3.0.0...v4.0.3) --- updated-dependencies: - dependency-name: fastmcp dependency-version: 4.0.3 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
b0894c8 to
35575d2
Compare
There was a problem hiding this comment.
Blocking at current head 35575d239cf7cce1716c494f9a58fc5da26ca190: the exact-head Python 3.11 and 3.12 test jobs both fail after resolving FastMCP 4.x, confirming the previously reproduced MCP session-persistence regression. Keep the <4.0.0 cap, or land a deliberate migration that preserves session state and passes the MCP transport suite before widening the range.
Sent by Cursor Automation: Release
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
1 participant
Updates the requirements on fastmcp to permit the latest version.
Release notes
Sourced from fastmcp's releases.
Changelog
Sourced from fastmcp's changelog.
... (truncated)
Commits
7129236Add v4.0.3 changelog entries (#5007)f79bc82chore: Update SDK documentation (#4945)6e0859ffix task timing field serialization (#5003)855cb7aClarify release title history lookup (#5006)6236ac1Clean up unfinished Monty callbacks (#5005)6c2fbe7docs: attribute the back-channel removal to SEP-2322/2575, not SEP-2577 (#4988)e68baccperf: avoid duplicate startup for mixed-era backends (#4971)032b9f6fix: don't infer an output schema for unconstrained sequences (#4999)75d50ffci: deploy docs through Mintlify's admin API and wait for a verdict (#4996)a338cfbdocs: point What's New at the changelog for later releases (#4992)Note
Low Risk
Single-line dependency bound change with no code changes; main risk is potential fastmcp 4.x API or behavior differences affecting MCP integrations at install time.
Overview
Relaxes the core
fastmcppin inpyproject.tomlfrom>=3.0.0,<4.0.0to>=3.0.0,<5.0.0, so installs can resolve fastmcp 4.x (including recent patch releases) while keeping the existing 3.x floor for MCP support.No application code changes—only the dependency constraint that governs what
pipmay install withopenenv.Reviewed by Cursor Bugbot for commit 35575d2. Bugbot is set up for automated code reviews on this repo. Configure here.