* fix: do not treat malformed JSON 200 as Accepted for requests
Streamable HTTP mapped any JSON body that failed to parse as
ServerJsonRpcMessage to Accepted, which is correct for notification
POSTs. For a request the worker then waits on SSE forever, so
call_tool hangs when the server returns 200 application/json with
an empty or non-JSON-RPC body.
Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
* fix: include a short body preview in JSON-RPC parse errors
Request POST parse failures now include a 256-byte prefix of the
unusable body so empty, HTML, and `{}` are distinguishable from the
serde diagnostic. HTTP reads bytes() then from_slice, matching Unix.
Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
---------
Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
* feat(auth): request ID-JAGs with enterprise refresh tokens
* feat(auth): exchange ID-JAGs for MCP access tokens
Redeem ID-JAGs at the approved resource authorization server and return
its bearer token, lifetime, and effective granted scopes. Preserve scope
narrowing and redacted diagnostics, and reuse the default HTTP adapter.
Support independently configured client authentication at both servers.
Document the exchange profile and test redirects and staged failures.
Partially addresses modelcontextprotocol/rust-sdk#531.
* test(conformance): cover EMA refresh-token exchange
* fix: allow concurrent streamable http requests
* fix: keep streamable http recovery responsive
Keep cancellation and replies available while old session POSTs finish.
Bound the wait for old POSTs and the replacement initialization handshake.
Do not retry interrupted POSTs because the server may have processed them.
Add regressions for recovery, queued cancellation, control timeouts, and
server replies needed by active requests.
* fix: preserve response and cancellation ordering
* refactor: clarify streamable http control flow
* fix: match stream responses against pending request ids
Match responses against all pending requests before removing a stream
registration. Keep distinct numeric and string ids separate while preserving
the existing fallback for servers that stringify numeric ids.
Add a mixed-id regression and keep a separate registration owner alive in
the abandoned-cancellation test.
* feat: make streamable http control timeouts configurable
* feat: implement SEP-2260 require server requests to associate with client requests
* feat(service): attach originating request id to in-handler outbound requests (SEP-2260)
Reuses the ORIGINATING_REQUEST task-local from #1027; the marker rides
the request's non-serialized Extensions so the streamable HTTP server
can route associated requests to the originating SSE stream.
* feat(transport): route associated server requests to originating SSE stream (SEP-2260)
* test: end-to-end SEP-2260 stream routing over streamable HTTP
* test: register SEP-2260 routing test with required-features; drop dead list_tools
* docs: document SEP-2260 association requirement and stream routing
* docs: fix redundant explicit link on OriginatingRequestId
* docs: note marker is role-agnostic; add reason to deprecated expect
Review follow-ups: the OriginatingRequestId rustdoc now states the marker
is attached for both roles with only the server transport reading it, and
the test's deprecation suppression carries a reason per house style.
* docs: condense inline comments to repo convention
Trims multi-line inline comments added in this branch down to the terse
one-to-two-line style used elsewhere in the codebase, keeping only the
non-obvious rationale (spec references, fallback invariant, version choice).
* docs: condense SEP-2260 rustdoc sections
Tightens the duplicated per-method association section from eleven lines
to five, and trims the marker and SessionManager docs to the same
information in fewer words.
* docs: single-source SEP-2260 caller requirements on OriginatingRequestId
* feat(service): reject unassociated server-to-client requests on the client (SEP-2260)
Implements the client receive-side of SEP-2260: restricted server
requests (sampling/createMessage, roots/list, elicitation/create)
received while the client has no outbound request in flight are
answered with -32602 invalid params instead of being dispatched to the
handler. Gated on negotiated protocol >= 2026-07-28; ping is exempt.
With a request in flight we cannot tell which one the server request
belongs to (SEP-2260 defines no wire field), so this is a deliberate
under-approximation of the spec's SHOULD; exact stream-based
enforcement for streamable HTTP needs receive-side provenance plumbing
and is left as a follow-up.
---------
Co-authored-by: Alex Hancock <alexhancock@block.xyz>
* feat!: implement SEP-2663 Tasks extension, removing the experimental 2025-11-25 tasks design
Reshape tasks from the experimental SEP-1319/1686 core-protocol feature into
the official io.modelcontextprotocol/tasks extension (SEP-2663):
Model:
- Re-model Task (statusMessage, ttlMs nullable, pollIntervalMs) and add
DetailedTask with status-discriminated payloads (inputRequests/result/error
inlined per spec)
- CreateTaskResult now flattens Task with resultType: "task";
add ResultType::TASK and CallToolResponse::Task
- Add tasks/update (UpdateTaskParams with MRTR InputResponses); tasks/get and
tasks/cancel reworked; remove tasks/list, tasks/result
- notifications/tasks now carries a full DetailedTask; removed from client
notifications (SEP-2260)
Capabilities:
- Remove core TasksCapability et al; tasks are declared via the extensions
map (enable_tasks() builders, supports_tasks() accessors)
- Remove tool-level execution.taskSupport and the _meta.task /
TaskMetadata / with_task() opt-in: task creation is server-directed and
gated on the per-request client capability
Runtime:
- Replace OperationProcessor with TaskManager: durable-before-response task
creation, input_required round-trips via tasks/update, cooperative
cancellation, TTL expiry
- Client peer helpers get_task/update_task/cancel_task
- Emit Mcp-Name routing header from params.taskId for tasks/* methods
(SEP-2243/2663)
Macros:
- Remove #[task_handler] and the tool execution() attribute
Tests/examples/docs updated; schema snapshots regenerated.
BREAKING CHANGE: the 2025-11-25 experimental tasks API is removed without a
compatibility shim. Clients that do not declare the tasks extension always
receive synchronous results.
* feat: gate tasks/* methods on the client tasks-extension capability (SEP-2663)
When the server advertises io.modelcontextprotocol/tasks but the client did
not declare it (per-request _meta clientCapabilities, or initialize-time
capabilities in session mode), tasks/get, tasks/update, and tasks/cancel now
return -32021 Missing Required Client Capability with the required extension
in the error data, instead of falling through to the handler's -32601
default. Servers that do not advertise the extension keep returning -32601.
Also add regression tests confirming that unknown taskIds yield -32602 and
that a legacy 2025-11-25 'task' param on tools/call is silently ignored.
* feat: pass SEP-2663 Tasks extension conformance suite
Conformance fixtures (conformance/src/bin/server.rs):
- Add the required fixture tools: greet (sync-only), slow_compute,
failing_job (task support: required), protocol_error_job, confirm_delete,
multi_input, and test_tool_with_task (MRTR -> task escalation), all backed
by TaskManager with server-directed task creation gated on the client's
tasks-extension capability
- Advertise io.modelcontextprotocol/tasks in server capabilities and wire
get_task/update_task/cancel_task handlers
- Task-required tools reject with -32021 when the client did not declare the
extension
SDK wire-shape fixes surfaced by the suite:
- Add resultType: "complete" to GetTaskResult and introduce TaskAckResult
so tasks/update and tasks/cancel acks carry the SEP-2322 discriminator
(spec: every non-CreateTaskResult response on the tasks surface is
resultType complete); dispatch now returns ServerResult::task_ack
- CreateTaskResult gets a strict deserializer requiring resultType: "task"
so it does not shadow task-shaped results in untagged unions
- Client update_task/cancel_task accept both TaskAckResult and EmptyResult
All 9 runnable Tasks extension server scenarios now pass (35/35 checks;
tasks-status-notifications remains upstream-skipped), so the corresponding
entries are removed from conformance/expected-failures-extensions.yaml.
2025-11-25 server suite (40/40), 2026-07-28 server suite (114/114), draft
client suite, and extensions client suite all pass their baselines.
* fix: address PR 1020 review feedback on DetailedTask schema and cooperative cancel
- DetailedTask's JsonSchema now derives from the actual flattened wire shape
(DetailedTaskWire: base Task + optional inputRequests/result/error) instead
of approximating with the base Task schema, so generated schemas for
GetTaskResult and notifications/tasks document the status-specific payload
fields. Golden message schemas regenerated.
- TaskManager::cancel_task no longer aborts the underlying future. It records
the observable cancelled state and acks immediately (spec's eventually
consistent semantics), but lets the operation keep running so it can observe
is_cancel_requested() or the error from a woken request_input() and perform
cleanup; any late result is discarded. New unit tests cover both the
cooperative-cleanup path and waking parked input requests.
* fix: make tasks/cancel truly cooperative per SEP-2663 (FEEDBACK_2)
- TaskManager::cancel_task no longer forces terminal 'cancelled'. It records
the cancellation intent, acks immediately, and wakes parked request_input
awaits, but the operation decides its own terminal state: a post-cancel
error settles as 'cancelled', while an operation that finishes its work
settles as 'completed' — per the spec, 'the task may still reach a
non-cancelled terminal status'.
- Add TaskContext::cancelled(), a watch-based await for use with
tokio::select! as the cooperative cancellation exit path.
- Correct the unsupported-notification method string from
'notifications/tasks/status' to 'notifications/tasks' and document that
task status notifications are not yet routable through subscriptions/listen
(SubscriptionFilter has no taskIds field; upstream check still skipped).
- Update conformance slow_compute fixture, task_demo example, and tests to
honor cancellation via ctx.cancelled(); lifecycle conformance still 8/8
(all 9 scenarios remain green, 35/35 checks).
* fix: sweep and evict expired tasks from TaskManager (FEEDBACK_3)
TTL handling previously only ran from get_task and only flipped overdue
non-terminal tasks to 'failed', never removing entries — an unbounded leak
for long-lived servers, and it made ttl_ms: None = 'unlimited retention'
meaningless since everything was retained forever.
- Rename expire_overdue to sweep_expired and run it from every entry point
(spawn, get_task, update_task, cancel_task).
- Track terminal_at on each entry; terminal tasks are evicted after being
retained for one further ttl_ms window past their terminal transition, so
well-behaved pollers can observe the final state before late tasks/get
calls return -32602 (spec: servers may delete expired tasks at any time,
and returning task-not-found for purged tasks is compliant behavior).
- ttl_ms: None entries are never evicted (spec: unlimited retention);
document the retention model on TaskManager, including that there is no
background sweeper.
- New tests: retention-window eviction, sweep of abandoned tasks via other
entry points, unlimited-TTL retention, and error-code assertions
(-32602) for unknown ids across get/update/cancel.
Reviewed the second feedback item (dedicated task-not-found error code)
against SEP-2663 §Protocol Errors and it is incorrect: the SEP explicitly
specifies -32602 (Invalid params) for invalid or nonexistent taskIds, which
is what unknown_task already returns. Kept -32602; strengthened tests to
assert the code.
* fix: address Copilot review feedback on PR #1020
- TaskManager: drop the JoinHandle as soon as the operation settles instead
of retaining it for the whole retention window, and only store it at spawn
time if the task is still non-terminal (avoids keeping a completed handle
that the completion path could never clear).
- Use RequestContext::client_capabilities() (which applies the initialize-time
fallback for session peers) instead of raw context.meta.client_capabilities()
in the task_demo example, the README snippet, and the test server — the
meta-only form would wrongly treat session-declared tasks clients as
unsupported.
All 9 Tasks extension conformance scenarios remain green (35/35 checks).
* fix: enforce SEP-2663 task-result gating in tools/call dispatch
A handler could return CallToolResponse::Task without checking whether the
request declared the io.modelcontextprotocol/tasks extension, sending a
CreateTaskResult to a client that cannot parse it. The SDK dispatch now
rejects that case with -32021 Missing Required Client Capability before the
response leaves the server, using RequestContext::client_capabilities()
(per-request _meta with initialize-time fallback).
Adds a regression test with a deliberately misbehaving handler that always
materializes a task; all Tasks extension conformance scenarios remain green
(35/35 checks).
* fix: align TTL boundary comparisons in sweep_expired
Copilot review: ttlMs: 0 never expired immediately because phase 1 used a
strict 'elapsed > ttl_ms' comparison, and phase 2 retained terminal tasks
at exactly the TTL boundary ('elapsed <= ttl_ms'). Treat elapsed >= ttl_ms
as expired in phase 1 and evict when elapsed >= ttl_ms in phase 2, so both
phases agree at the boundary and ttlMs: 0 expires/evicts on the first sweep.
* fix: strict TaskAckResult deserializer and TASK_REQUIRED_TOOLS consistency
- TaskAckResult carried only resultType (+ optional _meta) with a derived
Deserialize, so inside the untagged ServerResult union it greedily matched
any result object containing a resultType key, shadowing CustomResult and
losing data (verified with a probe). Replace with a strict deserializer:
deny_unknown_fields and require resultType == "complete". Regression
tests cover both the non-matching shapes and the genuine ack shape.
- Conformance fixtures: confirm_delete and multi_input rejected non-tasks
clients inline, contradicting the TASK_REQUIRED_TOOLS doc/constant. Move
them into TASK_REQUIRED_TOOLS (they park on in-task elicitation and have
no synchronous fallback) so the upfront -32021 gate is the single source
of truth, and drop the now-unreachable inline checks.
All 9 Tasks extension conformance scenarios remain green (35/35 checks).
* fix: let the operation decide its terminal state via TaskExit
After tasks/cancel, any operation error was coerced to terminal
'cancelled', masking real failures (e.g. an unrelated error landing just
after a late cancel request) and contradicting the documented 'operation
decides its own terminal state' contract.
Change TaskFuture's error type from McpError to a new TaskExit enum:
- TaskExit::Cancelled — an explicit cooperative-cancellation exit;
settles as terminal 'cancelled'.
- TaskExit::Error(McpError) — a real failure; settles as terminal
'failed' with the error inlined, even after tasks/cancel was received.
From<McpError> for TaskExit keeps '?' ergonomic in task bodies, and
request_input() now returns TaskExit directly (its wake-on-cancel path
yields TaskExit::Cancelled), so parked operations that propagate it with
'?' settle as 'cancelled' automatically.
Update the conformance fixtures, task_demo example, and tests; add a
regression test asserting a post-cancel unrelated error settles as
'failed' with its error payload preserved.
All 9 Tasks extension conformance scenarios remain green (35/35 checks).
* fix: allow TaskExit enum to be exhaustive
* fix: close spawn/shutdown race, sweep in running_task_count, clarify TTL retention docs
Addresses branch-review findings:
- spawn() raced with shutdown(): if shutdown drained the task map between
the entry insert and the JoinHandle store, the handle was dropped and the
operation kept running detached. If the entry is gone at store time, the
handle is now aborted instead.
- running_task_count() now runs the TTL sweep like every other entry point,
so it no longer reports overdue tasks as running (matching the documented
sweep-on-every-entry-point behavior). Regression test added.
- Document that terminal-task retention intentionally extends one ttl_ms
window past the terminal transition (observation grace period) beyond the
creation-based lifetime ttlMs advertises on the wire — compliant since
SEP-2663 allows deleting expired tasks at any time after the TTL.
A stateless streamable-HTTP request is one-shot (no session, no resumption),
so if the client drops the response before the handler finishes, the request
is terminal and should be cancelled. Previously the handler kept running with
its `RequestContext::ct` never firing, so long-running or destructive tools
could not observe a client disconnect.
Give each stateless request its own cancellation token via
`serve_directly_with_ct` and cancel it when the client disconnects. This covers
both stateless paths: `serve_negotiated_request_directly` (per-request version
negotiation) and the non-negotiated path. In each:
- A disconnect while the handler is still producing its first message cancels
it. The guard is disarmed once the handler emits anything, so a normal
response is never cancelled.
- The SSE response stream is wrapped in a guard that cancels the handler if the
stream is dropped before it ends naturally.
- When a negotiated request replies directly (JSON mode, or a non-OK status),
the receiver is dropped, so a still-running handler is cancelled rather than
left emitting into a closed channel. Without this its terminal send fails
before adding the termination permit and the serve loop parks forever.
Stateful (resumable) mode is intentionally left unchanged: there a disconnect
may be recovered via `Last-Event-ID`, so cancelling on disconnect would break
resumption.
Adds a regression test covering both stateless sub-modes (SSE and JSON).
* feat!: add MRTR behavior support
* feat: harden SEP-2322 MRTR support
* ci: diff public API only on features common to base and head
cargo public-api builds both revisions with the same feature set, so a
feature introduced (or removed) by a PR broke the build of the other
revision. Restrict the all-features diff to features present in both the
base and head revisions.
* fix(http): reduce latency on subsequent StreamableHttp calls
* refactor: rely on stream drain for connection reuse
* refactor: clean up comments and naming
* fix: restore pool_max_idle_per_host(0) for Linux
* feat(transport): add which_command for cross-platform executable resolution
Adds a `which_command()` helper that resolves executable paths via the
`which` crate before constructing a `tokio::process::Command`. This fixes
Windows failures where `.cmd` shim scripts (e.g. `npx.cmd`) are not
found by `Command::new()` without a fully-qualified path.
Closes#456
* refactor(transport): move which_command behind opt-in feature flag
Address review feedback: the `which` dependency is now gated behind a
separate `which-command` feature flag instead of being bundled into
`transport-child-process`. Users on Linux/macOS who don't need
cross-platform executable resolution no longer pull in the extra crate.
Also fixes the doc example import path to use the re-exported
`rmcp::transport::which_command`.
The `local` feature relaxes Send+Sync bounds, which causes items
gated behind `cfg(not(feature = "local"))` to be excluded when
docs.rs builds with all-features. Replace `all-features = true`
with an explicit feature list that omits `local`.
Signed-off-by: majiayu000 <1835304752@qq.com>
* feat(transport): add Unix domain socket client for streamable HTTP
MCP hosts in Kubernetes environments with Envoy sidecars need to route
HTTP through Unix domain sockets because DNS-based URIs only resolve
via the proxy. Adds UnixSocketHttpClient implementing StreamableHttpClient
using hyper over tokio::net::UnixStream, gated behind the
transport-streamable-http-client-unix-socket feature.
Also extracts RESERVED_HEADERS, extract_scope_from_header, and
validate_custom_header into common/http_header.rs to share header
validation logic between the reqwest and unix socket implementations.
* fix(transport): address review feedback for unix socket transport
- Document one-connection-per-request behavior on UnixSocketHttpClient
- Reject empty socket paths and bare '@' in constructor with assert
- Add explicit dep:http to unix-socket feature for self-documenting deps
- Document MCP-Protocol-Version exception on RESERVED_HEADERS constant
- Fix test catch-all to echo request id instead of hardcoding 1
- Remove leftover sleep(100ms) in test_unix_socket_custom_headers
- Add blank line before macro comment in Cargo.toml
* fix(transport): fix CI failures for unix socket transport
- Use std::io::Error::other() instead of Error::new(ErrorKind::Other)
to satisfy clippy::io_other_error on newer nightly
- Use #[tokio::test(flavor = "current_thread")] for unix socket tests
since axum's serve(UnixListener) requires spawn_local
- Gate validate_custom_header behind client-side-sse feature since it
references http::HeaderName which isn't available with default features
* fix(transport): fix CI failures for unix socket transport
axum::serve(UnixListener) uses spawn_local on Linux, which panics
outside a LocalSet. Replace with manual hyper HTTP/1.1 server that
accepts connections directly from the UnixListener, avoiding the
spawn_local requirement entirely.
* fix(transport): skip unix socket tests when local feature is enabled
The local feature causes ().serve(transport) to use spawn_local, which
requires a LocalSet. Gate the integration tests with not(feature = "local")
to match every other integration test in the repo.
* feat: add configuration for transparent session re-init
* fix: in ci revert running tests without local until all tests pass
* fix: pr comments
* fix: documentation
* fix(rmcp): surface JSON-RPC error bodies on HTTP 4xx responses
When a server returns a 4xx status with Content-Type: application/json,
attempt to deserialize the body as a ServerJsonRpcMessage before falling
back to UnexpectedServerResponse. This allows JSON-RPC error payloads
carried on HTTP error responses to be surfaced as McpError instead of
being lost in a transport-level error string.
Fixes#724
* fix(rmcp): surface JSON-RPC error bodies on HTTP 4xx responses
When a server returns a 4xx status with Content-Type: application/json,
attempt to deserialize the body as a ServerJsonRpcMessage before falling
back to UnexpectedServerResponse. This allows JSON-RPC error payloads
carried on HTTP error responses to be surfaced as McpError instead of
being lost in a transport-level error string.
Fixes#724
* fix(rmcp): only accept JsonRpcMessage::Error on non-success responses
* feat(streamable-http): add json_response option for stateless server mode
Adds `json_response: bool` field to `StreamableHttpServerConfig`.
When true and `stateful_mode` is false, the server returns
`Content-Type: application/json` directly instead of `text/event-stream`,
eliminating SSE framing overhead for simple request-response patterns.
This completes server-side JSON response support (client-side was added
in #540) and contributes to the stateless server goals of SEP-1442 (#526).
Backwards-compatible: `json_response: false` (default) preserves all
existing SSE behaviour unchanged, and `stateful_mode: true` is unaffected.
Benchmark evidence (50 VUs, 5min, 2 CPUs):
- RPS: 770 → 1139 (+48%)
- get_user_cart latency: 41ms → 0.76ms (-98%)
- checkout latency: 41ms → 0.55ms (-99%)
- Zero regressions, zero errors
* fix(tower): add cancellation awareness and logging to JSON response path
* fix(test): add missing Default to StreamableHttpServerConfig in concurrent streams test
Made-with: Cursor
* fix(streamable-http): return 409 Conflict when standalone SSE stream already active
LocalSessionWorker::resume() unconditionally replaced self.common.tx on
every GET request, orphaning the receiver the first SSE stream was
reading from. All subsequent server-to-client notifications were sent to
the new sender while the original client was still listening on the old,
now-dead receiver. notify_tool_list_changed().await returned Ok(())
silently.
This is triggered by VS Code's MCP extension which reconnects SSE every
~5 minutes with the same session ID.
Fix: Check tx.is_closed() before replacing the common channel sender.
If an active stream exists, return SessionError::Conflict which is
propagated as HTTP 409 Conflict. This matches the TypeScript SDK
behavior (streamableHttp.ts:423).
Signed-off-by: Mohammod Al Amin Ashik <maa.ashik00@gmail.com>
* fix(streamable-http): handle resume with completed request-wise channel
When a client sends GET with Last-Event-ID from a completed POST SSE
response, the request-wise channel no longer exists in tx_router.
Previously this returned ChannelClosed -> 500, causing clients like
Cursor to enter an infinite re-initialization loop.
Now falls back to the common channel when the request-wise channel is
completed, per MCP spec: "Resumption applies regardless of how the
original stream was initiated (POST or GET)."
* fix: allow SSE channel replacement instead of 409 Conflict
Per MCP spec §Streamable HTTP, "The client MAY remain connected to
multiple SSE streams simultaneously." Returning 409 Conflict when a
second GET arrives causes Cursor to enter an infinite re-initialization
loop (~3s cycle).
Instead of rejecting, replace the old common channel sender. Dropping
the old sender closes the old receiver, cleanly terminating the
previous SSE stream so the client can reconnect on the new stream.
This fixes both code paths:
- GET with Last-Event-ID from a completed POST SSE response
- GET without Last-Event-ID (standalone stream reconnection)
* fix: skip cache replay when replacing active SSE stream
When a client opens a new GET SSE stream while a previous one is
still active, the old sender is dropped (terminating the old stream)
and a new channel is created. Previously, sync() replayed all cached
events to the new stream, but the client already received those events
on the old stream. This caused an infinite notification loop:
1. Client receives notifications (e.g. ResourceListChanged)
2. Old SSE stream dies (sender replaced)
3. Client reconnects after sse_retry (3s)
4. sync() replays cached notifications the client already handled
5. Client processes them again → goto 2
Fix: check tx.is_closed() BEFORE replacing the sender. If the old
stream was still alive, skip replay entirely — the client already has
those events. Only replay when the old stream was genuinely dead
(network failure, timeout) so the client catches up on missed events.
* fix: use shadow channels to prevent SSE reconnect loops
When POST SSE responses include a `retry` field, the browser's
EventSource automatically reconnects via GET after the stream ends.
This creates multiple competing EventSource connections that each
replace the common channel sender, killing the other stream's receiver.
Both reconnect every sse_retry seconds, creating an infinite loop.
Instead of always replacing the common channel, check if the primary
is still active. If so, create a "shadow" stream — an idle SSE
connection kept alive by keep-alive pings that doesn't receive
notifications or interfere with the primary channel.
Also removes cache replay (sync) on common channel resume, as
replaying server-initiated list_changed notifications causes clients
to re-process old signals.
Signed-off-by: Myko Ash <myko@mcpmux.com>
Signed-off-by: Mohammod Al Amin Ashik <maa.ashik00@gmail.com>
* test: comprehensive shadow channel tests (15 cases)
Rewrite test suite for SSE channel replacement fix:
- Shadow creation: standalone GET returns 200, multiple GETs coexist
- Dead primary: replacement, notification delivery, repeated cycles
- Notification routing: primary receives, shadow does not
- Resume paths: completed request-wise, common alive/dead
- Real scenarios: Cursor leapfrog, VS Code reconnect
- Edge cases: invalid session, missing header, shadow cleanup
Fix Accept header bug (was missing text/event-stream for
notifications/initialized POST, causing 406 rejection).
* fix: use correct HTTP status codes for session errors per MCP spec
MCP spec (2025-11-25) section "Session Management" requires:
- Missing session ID header → 400 Bad Request (not 401)
- Unknown/terminated session → 404 Not Found (not 401)
Using 401 Unauthorized caused MCP clients (e.g. VS Code) to
trigger full OAuth re-authentication on server restart, instead
of simply re-initializing the session.
Signed-off-by: Mohammod Al Amin Ashik <maa.ashik00@gmail.com>
* fix: address review feedback — remove dead Conflict variant, restore sync on resume, rename test
- Remove unused SessionError::Conflict and dead string-matching in tower.rs
(leftover from abandoned 409 approach)
- Restore sync() replay when replacing a dead primary common channel so
server-initiated requests and cached notifications are not lost on reconnect
- Rename test from test_sse_channel_replacement_bug to test_sse_concurrent_streams
per reviewer suggestion (describe what tests verify, not what triggered them)
- Add test for cache replay on dead primary replacement
- Use generic "MCP clients" in comments instead of specific client names
Signed-off-by: Mohammod Al Amin Ashik <maa.ashik00@gmail.com>
* fix: use minimal buffer for shadow streams and cap at 32
- Shadow streams only receive SSE keep-alive pings, so use capacity 1
instead of full channel_capacity
- Cap shadow_txs at 32 to prevent unbounded growth from misbehaving
clients, dropping the oldest shadow when the limit is reached
- Add test verifying primary works after exceeding shadow limit
Signed-off-by: Mohammod Al Amin Ashik <maa.ashik00@gmail.com>
* fix: remove redundant single-component `use reqwest` import
Fixes clippy::single_component_path_imports lint error in
test_sse_concurrent_streams.rs.
---------
Signed-off-by: Mohammod Al Amin Ashik <maa.ashik00@gmail.com>
Signed-off-by: Myko Ash <myko@mcpmux.com>
Co-authored-by: Mohammod Al Amin Ashik <maa.ashik00@gmail.com>
* feat: add support for custom HTTP headers in StreamableHttpClient
* feat: implement reserved header checks for custom HTTP headers in StreamableHttpClient
* chore(deps): update rand requirement from 0.9 to 0.10
Updates the requirements on [rand](https://github.com/rust-random/rand) to permit the latest version.
- [Release notes](https://github.com/rust-random/rand/releases)
- [Changelog](https://github.com/rust-random/rand/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rust-random/rand/compare/rand_core-0.9.1...0.10.0)
---
updated-dependencies:
- dependency-name: rand
dependency-version: 0.10.0
dependency-type: direct:production
...
Signed-off-by: dependabot[bot] <support@github.com>
* fix: update rand import from Rng to RngExt for rand 0.10 compatibility
In rand 0.10, the Rng trait was renamed to RngExt. This updates the
imports in the example servers to use the new trait name.
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Alex Hancock <alexhancock@block.xyz>
