Possible memory leak using experimental feature Execution Cancellation

[gunters63]

Issue workflow progress

Progress of the issue based on the
Contributor Workflow

• 1. The issue provides a reproduction available on Github, Stackblitz or CodeSandbox

  Make sure to fork this template and run npm run generate in the terminal.

  Please make sure the GraphQL Tools package versions under package.json matches yours.

• 2. A failing test has been provided
• 3. A local solution has been provided
• 4. A pull request is pending review

---

Describe the bug

While analyzing a possible memory leak in a graphql-yoga server with Node.js heap profiling and Chrome dev-tools I saw some suspicious results which could indicate a memory leak in @graphql-tools/executor.

The first screen shot shows the comparison of two heap snapshots of the service, the latter one (Snapshot 4) received about 10000 mutation requests more than Snapshot 3. Memory is very stable except some new allocations, see the red frame. The number of new allocations is a multiple (x2, x4 or x6) of the received requests.

If I drill down the source of the allocations, it points to this place (@graphql-tools/executor/cjs/execution/execute.js):

To Reproduce Steps to reproduce the behavior:

If these are really some leaking event listeners every graphql-yoga server using @graphql-tools/executor should leak a little memory over time.

Expected behavior

No leaking listeners

Environment:

• OS: Arch Linux, Kernel 6.17
• @graphql-tools/...:
• "@graphql-tools/executor-http": "3.0.4",
• "@graphql-tools/merge": "9.1.1",
• "@graphql-tools/schema": "10.0.25",
• "@graphql-tools/stitch": "10.0.2",
• "@graphql-tools/utils": "10.9.1",
• "@graphql-tools/wrap": "11.0.1",
• "graphql": "16.11.0",
• "graphql-fields": "2.0.3",
• "graphql-scalars": "1.24.2",
• "graphql-tag": "2.12.6",
• "graphql-yoga": "5.16.0",
• NodeJS: 24.9.0

Additional context

Sorry that I didn´t provide tests or a reproduction repo (yet). Tests may be very difficult to write and if there is really a leaking listener problem one should be able to reproduce the issue (with Node.Js heap profiler and Chrome dev tools heap snapshot comparison) with every program using @graphql-tools/executor.

Maybe I am totally wrong here and the behavior I see in the snapshot comparison is normal.

[ardatan]

First of all, thank you for creating the issue!
It would be great if we can get some bare minimum setup that reproduces the issue because we have different test suites to check any potential memory leaks both in this repo and other projects that are using Yoga;
Tools -> https://github.com/ardatan/graphql-tools/blob/master/.github/workflows/tests.yml#L115
Yoga -> https://github.com/graphql-hive/graphql-yoga/blob/main/.github/workflows/ci.yml#L128
Hive Gateway -> https://github.com/graphql-hive/gateway/blob/main/.github/workflows/memtest.yml

About that event listener,
As you can see in the code, the event listener is registered when signal is set in the execution parameters;
Here -> https://github.com/ardatan/graphql-tools/blob/master/packages/executor/src/execution/execute.ts#L499
And GraphQL Yoga sets it when this plugin is used;
https://the-guild.dev/graphql/yoga-server/docs/features/execution-cancellation
Here -> https://github.com/graphql-hive/graphql-yoga/blob/main/packages/graphql-yoga/src/plugins/use-execution-cancellation.ts#L10
So it is disabled by default. That's why it'd be better if we learn more about your setup.
Maybe in the meanwhile, you can disable this plugin if you use it until we figure the issue out.

I also didn't see the version of @graphql-tools/executor you have in your code-base so maybe you can check if it is the latest by using a command like yarn why @graphql-tools/executor or any other variant of this depends on your package manager.

cc @enisdenjo

[gunters63]

Thanks for the quick reply. That is a lot of useful information.
Maybe I can create a simple example server now which reproduces the error.

Yes, I use useExecutionCancellation(), I will retry the leak test tomorrow without this. It is experimental anyway, I don´t really remember why I activated it in the first place.

Here the why output:

❯ pnpm why @graphql-tools/executor
Legend: production dependency, optional only, dev only

dependencies:
@graphql-tools/stitch 10.0.2
├─┬ @graphql-tools/batch-delegate 10.0.1
│ └─┬ @graphql-tools/delegate 11.0.1
│   └── @graphql-tools/executor 1.4.9
├─┬ @graphql-tools/delegate 11.0.1
│ └── @graphql-tools/executor 1.4.9
├── @graphql-tools/executor 1.4.9
└─┬ @graphql-tools/wrap 11.0.1
  └─┬ @graphql-tools/delegate 11.0.1
    └── @graphql-tools/executor 1.4.9
@graphql-tools/wrap 11.0.1
└─┬ @graphql-tools/delegate 11.0.1
  └── @graphql-tools/executor 1.4.9
@graphql-yoga/render-graphiql 5.16.0
└─┬ graphql-yoga 5.16.0 peer
  └── @graphql-tools/executor 1.4.9
graphql-yoga 5.16.0
└── @graphql-tools/executor 1.4.9

[gunters63]

Ok, I did two more tests now:

First I stressed it with bombardier using a simple query like:

bombardier -c 3 -d 60s -l -k -H 'content-type: application/json' -m POST -b '{"query":"{findManyLogin {Id} }"}' https://127.0.0.1:4400/graphql/drill.0

This also reproduced the leak with a simple query (i used a custom script using urql and mutations before).

Then I commented out useExecutionCancellation() in my code and re-ran the test. Bombardier made about 40000 requests in one minute.

This was the result:

Absolutely no + deltas anymore, the leak was gone.

[enisdenjo]

Thank you for digging into this, we really much appreciate it! I will be trying to reproduce this leak on our side and will come back to you with my findings.

[enisdenjo]

Ok, I tried a lot of things, I could not get it to leak. 🤔

I made a PR adding a memtest for both Hive Gateway (powered by Yoga) and Yoga itself with execution cancellation. No leaks reported. The memtests work the same way you test, it does a few runs of loadtesting, GCs in between runs, takes heap snapshots and then compares the deltas of each heap snapshot.

I did my local testing matching your Node version: 24.9.0.

You can run the memtests locally yourself with (make sure you have k6 installed):

MEMTEST=clean,keepheapsnaps,short yarn test:mem run execution-cancellation -t yoga

if it passes, you can double-check by loading, in order, the e2e/execution-cancellation/*.heapsnapshots into your DevTools and comparing them as you would.

Maybe Yoga setup for the test is too simple. Maybe there is something else happening.

If the tests pass for you locally too, we would kindly ask you to give more insights or create a reproduction so that we can test exactly that scenario. Thanks for helping us debug this!

[gunters63]

Ok,I got this to run on my dev machine.

I will gradually expand yoga-server.ts with my setup now until I (hopefully) can reproduce the problem.

[gunters63]

The first dependency from my service I added was fastify. So I modified yoga-server.ts from the test (see Fastify example:

import fastify, { FastifyReply, FastifyRequest } from 'fastify';
import {
  createSchema,
  createYoga,
  useExecutionCancellation,
  YogaInitialContext,
} from 'graphql-yoga';

export const schema = createSchema({
  typeDefs: /* GraphQL */ `
    type Query {
      hello: String
    }
  `,
  resolvers: {
    Query: {
      hello: () => 'world',
    },
  },
});

// This is the fastify instance you have created
const server = fastify({ logger: true });
// This will allow Fastify to forward multipart requests to GraphQL Yoga
server.addContentTypeParser('multipart/form-data', {}, (_req, _payload, done) => done(null))

// Create a Yoga instance with a GraphQL schema.
const yoga = createYoga<{
  req: FastifyRequest;
  reply: FastifyReply;
} | YogaInitialContext>({
  schema,
  plugins: [useExecutionCancellation()],
  logging: {
    debug: (...args) => args.forEach((arg) => server.log.debug(arg)),
    info: (...args) => args.forEach((arg) => server.log.info(arg)),
    warn: (...args) => args.forEach((arg) => server.log.warn(arg)),
    error: (...args) => args.forEach((arg) => server.log.error(arg)),
  },
});

server.route({
  // Bind to the Yoga's endpoint to avoid rendering on any path
  url: yoga.graphqlEndpoint,
  method: ['GET', 'POST', 'OPTIONS'],
  handler: (req, reply) =>
    yoga.handleNodeRequestAndResponse(req, reply, {
      req,
      reply,
    }),
});

// Start the server and you're done!
server.listen({ port: parseInt(process.env['PORT']!) }, (_error, serverUrl) => {
  console.info(`Server is running on ${serverUrl}${yoga.graphqlEndpoint}`);
});

Unfortunately, when I ran

MEMTEST=clean,keepheapsnaps,short yarn test:mem run execution-cancellation -t Yoga

I got an error from the test framework:

time="2025-10-10T11:24:16+02:00" level=error msg="test aborted: Status is not 200, got status 415 and body:\n{\"statusCode\":415,\"code\":\"FST_ERR_CTP_INVALID_MEDIA_TYPE\",\"error\":\"Unsupported Media Type\",\"message\":\"Unsupported Media Type: application/x-www-form-urlencoded\"} at default (file:///home/gunter/tmp/gateway/internal/perf/src/graphql-loadtest-script.ts:27:24(70))"

Not sure what causes this, if I start yoga-server.ts directly it behaves as expected.

[gunters63]

The next dependencies I'll try to add (if Fastify doesn´t trigger the memory leak) are:

• @graphql-tools/stitch
• @graphql-tools/wrap
• @graphql-tools/executor-http

[enisdenjo]

You can modify the internal/perf/src/graphql-loadtest-script.ts to match your servers requirements. Could be that the http.post somehow sends the wrong header assuming to post a form instead of json, are you running the latest k6?

[enisdenjo]

Did this to ensure content-type json, can you try with those changes?

[gunters63]

Just found this myself, yes running now :)

Results:

[gunters63]

Doesn't seem to be the same memory leak though (string, concatenated-string)