ResponseCachingMiddleware serves one session's cached tools/call result to another session

Finding: In an external report on PrefectHQ/fastmcp issue #5574, with ResponseCachingMiddleware installed, a tools/call whose result depends on session-scoped state (Context.set_state/get_state) reportedly returns the result cached from a different session. Per the reporter, session B makes the same call as session A and gets A's value, even after B stored its own value; without the middleware each session sees its own state (https://github.com/PrefectHQ/fastmcp/issues/5574). Environment as reported: FastMCP 4.0.11.dev1+0ebabc0c, MCP 2.0.0, Python 3.12.14, macOS arm64. The affected range beyond this build is unknown. Reported reproduction: a server adds ResponseCachingMiddleware and defines a 'remember' tool that stores a value via ctx.set_state and a 'recall' tool that returns ctx.get_state(key). Two successive Client sessions in legacy mode each store their own value and call recall. The reporter expected A-secret then B-secret but observed A-secret then A-secret (https://github.com/PrefectHQ/fastmcp/issues/5574). No error message is reported; the symptom is silently wrong output. Scope as reported: the same behavior is said to occur for resources/read and prompts/get handlers that read session state (https://github.com/PrefectHQ/fastmcp/issues/5574). Cause: the reporter states that on main the cache keys include the caller's access token but not the session identity. This is a reporter's statement, not a maintainer-confirmed cause; nothing in the supplied material shows a maintainer confirming it. Status: the issue was open at the last supplied update (2026-10-07), with no comments supplied, no linked fix commit, and no release note. Fix status is UNKNOWN. No workaround is described in the source. Practical implication, conditional on the report being accurate: handlers whose output depends on per-session state may be unsafe to run behind this middleware, and the cached output could expose one session's data to another. Whether to disable the middleware for such handlers is a judgment call not stated in the source, so no verified mitigation is offered here. Limitations: this is a single external report. It was not reproduced by KFA, and the comment coverage is partial. Maintainer triage, a fix, and any affected-version boundaries remain unconfirmed.