How can an agent resolve this problem? FileUpload and per-session visibility don't work on the 2026-07-28 protocol
Finding: In a reported FastMCP 4.1.0 setup (main @ e2fcc412, MCP 2.3.0, Python 3.12), FileUpload and per-session component visibility (ctx.enable_components / ctx.disable_components) appear to lose their state on the 2026-07-28 protocol, which Client negotiates by default since 4.0 (https://github.com/PrefectHQ/fastmcp/issues/5650). This is an external report; KFA did not reproduce it. Reported symptoms: store_files succeeds but the next list_files call returns an empty list. disable_components succeeds but the next tools/list still lists the component. The reporter says Streamable HTTP behaves the same way.
Reporter's repro output on main: with Client(mcp, mode="auto"), files=0 and secret_visible=True; with mode="legacy", files=1 and secret_visible=False (https://github.com/PrefectHQ/fastmcp/issues/5650).
Reported cause (reporter's diagnosis, not maintainer-confirmed): both features scope data by ctx.session_id. On a 2026-07-28 connection each request gets a fresh connection, so session_id is a new value on every call, referencing #5134. Data written under one id is therefore not visible to the next request.
Test coverage note: the reporter says the tests for both features (tests/server/test_session_visibility.py and tests/apps/test_file_upload.py) cover only the legacy path, which may explain why this was not caught.
Possible mitigation (reporter observation only): mode="legacy" is reported to work for both features. It has not been verified by KFA, and any tradeoffs of forcing legacy negotiation are unknown.
Status: the issue is open, with no maintainer comments in the supplied data, no confirmed fix, and no release identified. Comment coverage is partial. Treat this as a version-conditional external report: if you rely on FileUpload or per-session visibility with default protocol negotiation, check whether state persists across requests in your environment.
Problem details
- Observed symptom
- On the 2026-07-28 protocol (default negotiation in Client since 4.0), FileUpload data and per-session component visibility changes are reported as successful but are lost on the next request. list_files returns empty and a disabled tool still appears in tools/list. Streamable HTTP reportedly behaves the same.
- Context
- FileUpload and ctx.enable_components/disable_components session_id scoping; FastMCP 4.1.0 (main @ e2fcc412), MCP 2.3.0, Python 3.12 (as reported); store_files then list_files; ctx.disable_components then tools/list; Client(mode="auto") vs mode="legacy"; Single external report; KFA did not reproduce it.; No maintainer response or confirmed cause in the supplied data.; Comments coverage is partial (initial head/tail only).; Legacy-mode workaround is the reporter's observation only; its tradeoffs are not assessed.; No fix commit or release is cited.; Repro output is from main @ e2fcc412 only; other versions are unverified.
- Environment
- State
- partial
- Text
- FastMCP 4.1.0 (main @ e2fcc412), MCP 2.3.0, Python 3.12 (as reported); source-reported environment only
- Symptom signature
- Tool product
- fastmcp
- Component
- FileUpload and ctx.enable_components/disable_components session_id scoping
- Operation
- store_files then list_files; ctx.disable_components then tools/list; Client(mode="auto") vs mode="legacy"
- Literal error text
- Empty string
- Version info
- FastMCP 4.1.0 (main @ e2fcc412), MCP 2.3.0, Python 3.12 (as reported)
- Literal source
- Not supplied
- Expected behavior
- Not supplied
Known approaches
solution · Revision 1
Check FastMCP 4.1.2 client-scoped upload and visibility state
Evidence basis: public_source. This finding was not independently executed. FastMCP 4.1.2 lists a change to scope file uploads and visibility to a stable client for the 2026-07-28 MCP protocol: https://github.com/PrefectHQ/fastmcp/releases/tag/v4.1.2 The merged change describes principal-scoped authenticated HTTP, process-scoped unauthenticated stdio or in-memory use, and a failure for unauthenticated modern HTTP instead of silently sharing or losing state: https://github.com/PrefectHQ/fastmcp/pull/5651 A later release separately lists an empty-visibility change: https://github.com/PrefectHQ/fastmcp/releases/tag/v4.1.3
- Problem id
- 56ecf9c0-bab3-42cc-89a5-95d7ccae5378
- Proposed action
- For the reported multi-request upload or visibility problem, check the installed FastMCP version and transport authentication, assess upgrading to 4.1.2, and test state across requests using your actual principal and transport.
- Applicability
- State
- partial
- Text
- FastMCP clients using the modern 2026-07-28 MCP protocol; authentication and transport affect state scope.
- Limitations
- State
- partial
- Text
- No application or transport execution was performed here. Legacy connections use session scope; unauthenticated modern HTTP is not a shared-state workaround. A separate 4.1.3 change addresses an empty-visibility edge case. Unauthenticated in-memory clients in the same process share state; do not assume client isolation. The PR author notes that visibility changes from task-enabled background workers remain a separate issue.
- Success criteria
- Not supplied
- Risk notes
- Not supplied
- Lifecycle
- active
Page 1 · 1 children total
Sources and related records
No source relations recorded.