Skip to content

Miniflare Durable Objects polyfill conflicts with Sentry instrumentation #9169

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
AbhiPrasad opened this issue May 7, 2025 · 5 comments
Closed
Labels
agents bug Something that isn't working miniflare Relating to Miniflare

Comments

@AbhiPrasad
Copy link

AbhiPrasad commented May 7, 2025

Which Cloudflare product(s) does this pertain to?

Miniflare

What versions & operating system are you using?

MacOS (but should apply everywhere), Wrangler compat-date 2025-03-21

Please provide a link to a minimal reproduction

getsentry/sentry-mcp#134 - clone the repo at this commit

Describe the Bug

Sentry has instrumentation for @modelcontextprotocol/sdk package, released in 9.13.0 of the Sentry SDKs.

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

// Create an MCP server
const server = new McpServer({
  name: 'Demo',
  version: '1.0.0',
});

// Use the instrumented server in your application
const instrumentedServer = Sentry.wrapMcpServerWithSentry(server);

Under the hood, this monkeypatches the MCP instance via Proxies: https://github.com/getsentry/sentry-javascript/blob/57893e2e61a2677fffd8bfc226f0ed60097500f3/packages/core/src/mcp-server.ts#L49

It seems like Miniflare is using a polyfill for private class fields/methods. The MCP transport that the cloudflare agents library configure uses private fields/methods. The polyfill minflare seems to work by doing WeakMap<Transport, PrivateField> mappings.

The Sentry instrumentation intercepts whatever transport is passed into the MCP server, Proxys it and forwards it to the MCP server. The problem is that the proxying is actually changing the identity of the transport, which will break the WeakMap.

Image

Image

Image

Is it possible we can improve this polyfill so we don't break proxies? We rely on this for instrumentation, and theres not a better way to patch the library for now.

As an alternative, we could disable the patching just in miniflare, but we'd need a good way to detect this.

Please provide any relevant error logs

The error message we get is not very useful:

3:24:55 PM [vite] Internal server error: Cannot read from private field
@sentry/mcp-cloudflare:dev:       at async ProxyServer.fetch (file:///home/dcramer/src/sentry-mcp/node_modules/.pnpm/[email protected]/node_modules/miniflare/src/workers/core/proxy.worker.ts:173:11)
^C    ...Finishing writing to cache...   

ref: getsentry/sentry-mcp#136

@mhart
Copy link
Contributor

mhart commented May 9, 2025

FWIW the polyfill is from esbuild – that's how it transforms private fields (including the WeakMap stuff)

@petebacondarwin
Copy link
Contributor

petebacondarwin commented May 9, 2025

I have dug around a bit and it seems that the problem is actually with the build of the Cloudflare Agents library.
These WeakMaps are being injected into the distributable code that is then being imported in the sentry-mcp repo above.
You can find the code at packages/mcp-cloudflare/node_modules/agents/dist/mcp/index.js line 71.

This is the line that probably needs fixing: https://github.com/cloudflare/agents/blob/main/tsconfig.base.json#L14
From the typescript docs ES2021 or below maps private fields to WeakMaps in place of #.

@petebacondarwin
Copy link
Contributor

I created an issue on the Agents repo: cloudflare/agents#264

@threepointone
Copy link
Contributor

Fixed in [email protected]

@AbhiPrasad
Copy link
Author

thank you all!

@github-project-automation github-project-automation bot moved this from Untriaged to Done in workers-sdk May 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agents bug Something that isn't working miniflare Relating to Miniflare
Projects
Status: Done
Development

No branches or pull requests

4 participants