Random NS_ERROR_NET_PARTIAL_TRANSFER in Mozilla Firefox

[pablovargasosorio]

Describe the bug

When using Mozilla Firefox in my local Angular project I have a random network issue while loading the JS chunks: NS_ERROR_NET_PARTIAL_TRANSFER
It's working fine in Chrome or any other browsers.

The issue was introduced after upgrading my Angular project from v20 to v21. I confirmed the ViteJS lib was changed from 7.1.5 to 7.2.2. And also confirmed the issue is not reproducible when downgrading to Angular v20/Vite 7.1.5.

Vite version where the issue is not reproducible:
└─┬ @angular/build@20.3.3
├─┬ @vitejs/plugin-basic-ssl@2.1.0
│ └── vite@7.1.5 deduped
└── vite@7.1.5

Vite version with reproducible issue:
└─┬ @angular/build@21.0.5
├─┬ @vitejs/plugin-basic-ssl@2.1.0
│ └── vite@7.2.2 deduped
└── vite@7.2.2

• Note: I cannot add a reproducible scenario because it only fails on 'big' projects with many chunk.js resources.

Reproduction

n/a

Steps to reproduce

• Use Mozilla Firefox in a Angular project v20 (with Vite 7.1.5)
• Upgrade Angular using ng upgrade so we go to the latest, and internally it will upgrade Vite to 7.2.x
• Use Firefox and reload the page (hard reload with Shift + reload) Do it several times and you'll see in the 'Network' tab some of the requests are failing with error NS_ERROR_NET_PARTIAL_TRANSFER

• Environment: Angular CLI dev-server (@angular/build:dev-server) with SSL certificates enabled (HTTP/2)

System Info

System:
    OS: macOS 26.2
    CPU: (8) arm64 Apple M1 Pro
    Memory: 286.56 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.0.0 - /Users/name/.nvm/versions/node/v24.0.0/bin/node
    npm: 11.3.0 - /Users/name/.nvm/versions/node/v24.0.0/bin/npm
    pnpm: 9.12.1 - /opt/homebrew/bin/pnpm
  Browsers:
    Chrome: 144.0.7559.110
    Edge: 144.0.3719.104
    Safari: 26.2

Used Package Manager

npm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[sapphi-red]

It is impossible to investigate without a reproduction. At least more information like detailed logs output by Firefox is required.
It's also not clear whether it's actually caused by Vite itself. It could be caused by something in angular or Firefox or other tools.

[LostDragonist]

I'm still trying to get some better data but I can echo most of the initial report. Node 22.22.0, Angular 21.0.6, Vite 7.2.2, SSL enabled, large projects failing to download chunks. Firefox transfers fail with NS_ERROR_NET_PARTIAL_TRANSFER while Chrome just keeps the transfers pending forever.

[jordanade]

I've had this issue for some time. See discussion here:
#18248

Would be happy to provide logs if instructed how.

[iNaD]

This bugged us since we upgraded Vite in the past (the switch for Proxying with http/2 instead of http/1.1) and also affects Webkit (Safari) on iOS and Mac.

Disclaimer: The following research and fix were done together with Claude Opus 5.5

Claude's Summary

We're hitting the same bug (Angular 22 → `@angular/build` 22.1.8 → Vite 8.1.5, Firefox 153 and Safari, cold cache, ~250 modules on first load) and traced it down to the wire. Sharing in case it helps reopen this.

Why it started with Vite 7.2

#20869 (7.2.0) made the dev server use HTTP/2 even when server.proxy is set. Before, resolveHttpServer fell back to node:https (HTTP/1.1) for proxied setups. The Angular dev server passes proxy whenever proxyConfig is used, so with ssl: true + proxyConfig those apps moved to HTTP/2 with 7.2 — which matches the 7.1.5 → 7.2.2 boundary reported above.

What happens on the wire

Firefox HTTP log (MOZ_LOG=timestamp,sync,nsHttp:5) for one failed module (chunk-D52UA2OL.js, 7124 bytes):

Http2Session::WriteSegments[…] Frame Header Read type 1 data len 37 flags 4 id 0x29        ← HEADERS
Http2Session::WriteSegments[…] Frame Header Read type 0 data len 7124 flags 0 id 0x29      ← DATA, full body, no END_STREAM
Start Processing Data Frame. Session=… Stream ID 0x29 … Fin=0 Len=7124
Http2Session::WriteSegments[…] Frame Header Read type 3 data len 4 flags 0 id 0x29         ← RST_STREAM
Http2Session::RecvRstStream … RST_STREAM Reason Code 0 ID 29
Http2Session::CleanupStream … 0x29 804B004C                                                 ← NS_ERROR_NET_PARTIAL_TRANSFER

The server sends the complete body, then RST_STREAM(NO_ERROR) — but never a frame with END_STREAM. HTTP/2 responses carry no content-length here, so Firefox can only conclude the transfer was cut. If it hits an eagerly imported module (we saw zone.js), the app never boots and the page stays white.

On the server, Node considers every stream finished cleanly (NODE_DEBUG=http2: closed with code 0, writable side fully written, no session errors or GOAWAY).

Cause

Node's Http2Stream[kMaybeDestroy] (lib/internal/http2/core.js) "gracefully" closes server streams once the response is finished, as long as the request body was never read:

if (this.headersSent && this[kSession][kType] === NGHTTP2_SESSION_SERVER &&
    !(state.flags & STREAM_FLAGS_HAS_TRAILERS) && !state.didRead &&
    this.readableFlowing === null) {
  setImmediate(callStreamClose, this);   // → stream.close() → RST_STREAM(NO_ERROR)
}

That reset can overtake the final END_STREAM frame. RFC 9113 §8.1 only allows RST_STREAM(NO_ERROR) after a complete response. Vite's request handlers never read GET request streams, so every module response is eligible. Reproduced identically on Node 24.18.0 and 26.5.1.

Workaround (verified)

Mark bodyless request streams as read so the graceful close never fires; the stream then closes normally after END_STREAM:

// packages/vite/src/node/http.ts → resolveHttpServer
const server = createSecureServer({ /* … */ allowHTTP1: true }, app)
server.on('stream', (stream) => {
  if (stream.endAfterHeaders) stream.resume()
})
return server

endAfterHeaders is set before the stream event is emitted, so streams with a body (e.g. proxied POSTs) are left alone and can't lose chunks to a late reader.

Firefox, 20 cold loads each	Loads with a truncated module
HTTP/2, unpatched	14–15 / 20
HTTP/1.1 (node:https)	0 / 20
HTTP/2 + workaround	0 / 20

Safari was also clean with the workaround. We ship it as a yarn patch for now.

Reproduction

We couldn't reduce it to a standalone node:http2 server — a plain compat server serving 250 ES modules with res.end(body) stays clean, even with large bodies and a slow-reading client — so something in the timing of the real dev server makes the race likely. It reproduces reliably with any larger Angular app served with ssl: true + proxyConfig, using fresh browser contexts for empty caches:

// Playwright, Firefox
for (let i = 0; i < 20; i++) {
  const ctx = await browser.newContext({ ignoreHTTPSErrors: true })
  const page = await ctx.newPage()
  page.on('requestfailed', (r) => console.log(i, r.url(), r.failure()?.errorText))
  await page.goto('https://localhost:4200/', { waitUntil: 'load' })
  await page.waitForLoadState('networkidle')
  await ctx.close()
}

Since the root cause is Node's graceful close, the cleanest place for a fix may be Node itself, but the workaround is small and only affects bodyless requests on Vite's HTTP/2 server.

@sapphi-red if this is enough for you to reproduce, I could provide a PR with the fix or you decide we should report this upstream. Hope the AI usage is okay, but without AI I couldn't have debugged this myself.

[sapphi-red]

Would you create an issue in Node? We can have a PR linking to that issue if that takes more than a month.

[iNaD]

Could reproduce it without vite, so upstream issue is created: nodejs/node#66525

[iNaD]

A month has passed, it's fixed in main but wasn't fully backported. Don't know how we continue now, we still have the patch for vite in our project and re-apply it on each update of vite. If you want to we could add the workaround as PR to vite or just wait until the next stable release of node contains the fix.