GraphQL diagnostics_channel tracing publishes non-structured-cloneable payloads in Cloudflare Workers Tail Workers

[astanciu]

GraphQL.js 17 resolves node:diagnostics_channel at module load and creates graphql:* tracing channels.

In Cloudflare Workers with nodejs_compat and a Tail Worker attached, Cloudflare forwards diagnostics channel messages to Tail Workers as diagnosticsChannelEvents. That forwarding appears to require structured-cloneable payloads.

GraphQL diagnostic contexts include objects like GraphQLSchema, DocumentNode, Source, execution results, resolver args/results, etc. Some of these are not structured-cloneable. In production this causes Cloudflare runtime log errors like:

Failed to publish diagnostics channel message:

The request itself still succeeds; logs get polluted with runtime errors.

Reproduction shape

1. Deploy a Cloudflare Worker with:
   • compatibility_flags = ["nodejs_compat"]
   • a Tail Worker configured
   • GraphQL.js 17
2. Execute a GraphQL request through GraphQL Yoga or direct GraphQL.js parse/validate/execute.
3. Runtime logs repeatedly show:

Failed to publish diagnostics channel message:

This happens even without application-level OpenTelemetry.

Relevant GraphQL.js behavior

graphql/diagnostics.mjs does:

const dc = resolveDiagnosticsChannel();
export const parseChannel = dc?.tracingChannel('graphql:parse');
export const validateChannel = dc?.tracingChannel('graphql:validate');

and emission sites trace when channel.hasSubscribers is true.

On Cloudflare, Tail forwarding appears to act as a diagnostics subscriber, so tracing is enabled even when the app did not intentionally subscribe to GraphQL diagnostics.

### Expected behavior

GraphQL.js 17 should work in Cloudflare Workers with Tail Workers enabled without runtime diagnostics errors.

Possible fixes:

- expose an official opt-out for GraphQL diagnostics tracing,
- avoid publishing non-structured-cloneable objects by default,
- provide serialization/sanitization hooks,
- or avoid enabling tracing for infrastructure-level diagnostics forwarding.

### Workaround

We patched resolveDiagnosticsChannel() to return undefined, disabling GraphQL diagnostics entirely. That works, but it is brittle and disables useful instrumentation.

[yaacovCR]

Tagging @logaretm.

I see there’s an additional linked issue on the tail worker side, I wonder if there is an additional transformation to structured clonable objects that should happen at that step?

[logaretm]

I think this behavior is not desirable in tail workers because it means every other library will run into the same thing. Spec-wise there is no limitation on the context object containing non-serializable values.

Also, subscribers are encouraged to mutate the context object and attach their own data to it. In the observability space that would most certainly be span objects, scope, context, etc... all of which are not perfectly serializable.

Thinking of our options here:

avoid publishing non-structured-cloneable objects by default

It would work by default, so we need to omit a few things like resolver path getters, and ensure we don't publish the document object. Still, subscribers will attach their own stuff and those may not be serializable. So realistically it would only solve it for plain workers with GraphQL without any kind of subscribers.

This would also limit the info available to the instrumentations which is not ideal as we already aligned what is being published with OTel conventions.

Could a handicapped toJSON method on the context object work? where it would skip over non-clonable objects? I will need to take a look at how tailworkers try to clone stuff.

or avoid enabling tracing for infrastructure-level diagnostics forwarding.

I don't see this being detectable or knowable at runtime at all, an explicit disable method would work tho.

So it looks like we can either:

• Expose a disable method that shuts the whole thing down.
• Do nothing, as every other library will have the same issue like Redis, ai-sdk, mysql etc...

What do you folks think?

[yaacovCR]

I have no objection to adding a global disable as a temporary workaround if there is no significant overhead. Although it does not seem like the ideal solution. Might make sense to wait for a response at the cloudflare end as @astanciu already has a workaround in place.

[logaretm]

@astanciu I was looking at some stuff, and I'm curious which is your current compatibility date configured?

Can you try to see if >= 2026-05-19 fixes it?

[logaretm]

@yaacovCR I think we can wait, I posted some findings there. I do not think this is something GraphQL needs to handle right away since it affects the entire ecosystem and everything we have here is spec-compliant.