Memory leak with axios and AbortSignal in middleware in next >=15.4

[liammcateer]

Link to the code that reproduces this issue

https://github.com/liammcateer/next-abort-signal-memory-leak-reproduction

To Reproduce

1. Run npm install
2. Build the next app: npm run build
3. Run the mock server in a separate terminal window: node mockServer.js
4. Start the next app: npm run start
5. Make many requests (I do 1,000) to a single page
6. Take a heap snapshot using kill -USR2 <next-server PID>. You can find the PID by running ps aux | grep "next-server (v15.5.5)"
7. Open the heap snapshot in chrome dev tools and look for increasing memory
8. Repeat steps 5-7 with all other pages.

You will notice that /middleware/axios is the only one that increases memory. You can also verify this by leaving the server running for a little bit and noticing that the memory is never returned.

Current vs. Expected behavior

I expect that fetching an API with axios using the AbortSignal should not cause a memory leak.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.3.0: Thu Jan  2 20:24:16 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 8
Binaries:
  Node: 22.14.0
  npm: 10.9.2
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 15.5.5 // No Next.js version data was found.
  eslint-config-next: 15.5.5
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Middleware

Which stage(s) are affected? (Select all that apply)

next start (local), Other (Deployed)

Additional context

Tested against different canary releases, the first one that introduced the issue is 15.4.0-canary.95. 15.4.0-canary.94 does not have the issue.

When using axios to call an API inside middlware.ts with an AbortSignal, a memory leak appears.
This code will reproduce the issue:

export async function middleware(req: NextRequest) {
  await axios.get('https://<some-api>/', {
    signal: AbortSignal.timeout(1000),
    adapter: 'fetch',
  });

  return NextResponse.next();
}

If the AbortSignal is removed, or fetch is used instead of axios with an AbortSignal, the issue goes away.

In my reproduction, I called the same api using fetch and axios in both middleware.ts and page.tsx. The issue is only present when axios is used in middleware.ts. Each request was made 1000 times.
Here is a screenshot of various heap snapshots taken after each test. You can see that when axios is used in middleware, the problem presents. I also took another snapshot 30 seconds later, and the memory was still not released. I have also taken some snapshots (not shown) where I left the app for 15 mins, and the memory was still not released.

This screenshot shows quite a few (over 2000) {signal,abort} objects hanging around

I understand that calling APIs in middleware is an anti-pattern, however, this used to work previously, so should be reported as a bug. I also understand that there is a workaround to use fetch instead of axios. Our generated API fetching code uses axios, so our team would need to spend some effort to migrate away from axios. We are using axios with the fetch adapter.

[icyJoseph]

Are you able to reproduce this w/ Axios in the browser only? In middleware I'd assume Axios uses the browser implementation 🤔 - Are you also able to reproduce this if you use runtime nodejs? https://nextjs.org/docs/app/api-reference/file-conventions/middleware#runtime

[icyJoseph]

Hi, I missed that you had bisected two canaries, I wonder if you could try with these hashes:

• 52372be7cbefb97459df9f7633dba89bb50d8391
• 62fa7fa16daffb431741788c29d0c0a02e84cfa6

Replace the next version in your package.json with https://vercel-packages.vercel.app/next/commits/<commit-hash>/next - install and run your tests. Looking at the changes here, v15.4.0-canary.94...v15.4.0-canary.95, I have a fair suspicion that perhaps minification is doing something wrong.

My hypothesis is that 62fa... should not have the memory leak.

[liammcateer]

Are you able to reproduce this w/ Axios in the browser only? In middleware I'd assume Axios uses the browser implementation 🤔 - Are you also able to reproduce this if you use runtime nodejs? https://nextjs.org/docs/app/api-reference/file-conventions/middleware#runtime

The leak is still present when running on next@15.5.5 with runtime: 'nodejs' in middleware.ts

[liammcateer]

Replace the next version in your package.json with https://vercel-packages.vercel.app/next/commits/<commit-hash>/next - install and run your tests.

I'm getting npm error 410 Gone when trying to install those, looks like they might have been removed since the runs are no longer available.

I tried building next locally, but I wasn't able to reproduce in any v15.4.0-canary.94...v15.4.0-canary.95 commits. I'm not sure I was doing it correctly.

[liammcateer]

I also tried building without turbo, and found that the issue appears slightly earlier in 15.4.0-canary.81. 15.4.0-canary.80 doesn't have the issue when using turbo.

[icyJoseph]

Ah such bad luck when those packages don't work out...

It could be an SWC issue, but how do we even try to reproduce the bad minification. One thing you can is disable serverMinification on your webpack builds:

module.exports = {
   experimental: {
      serverMinification: false
   }
}

If that fixes it, then we have a strong candidate.

[liammcateer]

Yea, that appears to fix the leak when not using turbo. Setting serverMinification: false doesn't fix the leak on it's own, but it does when the middleware runtime is set to nodejs

[icyJoseph]

I think there's an experimental, turbopackMinify flag, final test, does that fix the issue in Turbopack?

[liammcateer]

Yep, setting turbopackMinifiy: false works. Also works for both middleware runtimes.

[icyJoseph]

Good stuff. First of all, thanks for the effort and time you've put into this. I guess, we should now try to see the middleware build output in a good canary (so that it is minified but not leaky), and then capture the build output in a bad version.

[r34son]

There was SWC update #80659

[liammcateer]

I've managed to get the local next build working, with different swc_core versions. I tested with v28 and v29, and both have the leak. v27 does not, so it must be something that was added in the commits between 27.0.6 and 28.0.0 releases.
swc-project/swc@3cbe356...5ee6dc0

Maybe @kdy1 might know?