You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
MCP server wrapper misses messages delivered during transport start #23977
wrapMcpServerWithSentry instruments an MCP transport only after the wrapped
server's connect() promise resolves. Both supported MCP TypeScript SDK
generations install their transport callbacks and then call transport.start() before that promise resolves.
A transport is allowed to deliver already-buffered messages from start().
The official InMemoryTransport does this in both SDK v1.30.0 and v2.0.0. If
an initialize request is queued before the server connects, that first
request reaches the server before Sentry wraps onmessage, so no MCP span is
created for it.
Reproduction
Create an official linked InMemoryTransport pair.
Start Client.connect() first so its initialize request is queued on the
server transport.
Connect a server wrapped with wrapMcpServerWithSentry.
Inspect the emitted MCP spans.
Actual behavior
The queued initialize request is handled during transport.start() and is
missing from Sentry. Later requests are instrumented after connect()
completes.
Expected behavior
Instrument the callbacks after the MCP SDK installs them but before transport.start() can deliver its first message.
Preserve the transport's start() receiver, promise, errors and property
shape.
Restore the temporary interception after the connection attempt.
Preserve the existing post-connect behavior for transports whose start
method cannot be intercepted or is not invoked.
Capture the first request exactly once in MCP SDK v1 and v2, both in v11's
default Sentry-only mode and its optional Sentry-managed
OpenTelemetry-compatible mode (enableOpenTelemetrySetup: true).
Activity
linear-code commentedon Sep 2, 2026
JS-3554
fix(core): instrument MCP transports before start (#23978)
github-actions commentedon Sep 23, 2026
A PR closing this issue has just been released 🚀
This issue was referenced by PR #23978, which was included in the 11.0.0 release.