Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Abort "Lazy deopt after a fast API call with return value is unsupported" in Buffer.byteLength called from maybePrepareFinalChunk / res.end(string)

Offen
  • Stimmt etwas nicht?
#66,870 6 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@ronag arbeitet bereits daran.

Seit 30.10.2026.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
42/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
javascript, node.js
Bereich
backend, networking

Rechercherichtung

Start by reading lib/_http_outgoing.js at maybePrepareFinalChunk and the Buffer.byteLength implementation in lib/buffer.js; trace how res.end(string) reaches the fast API call. The report has no standalone reproduction, so first reproduce on Linux with the described sustained Vite workload or create a focused test that exercises the aborting path. Done means the process handles the request without aborting and the regression is covered by a test.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Version

v26.10.0 (node-26.10.0-linux-x64 from actions/setup-node@v5).

The same abort also occurred on 2026-08-28 in a second CI run on the then-current 26.x build, so it is not a one-off.

Platform
Linux 6.x x64 (GitHub Actions ubuntu-latest runner)

All local attempts to reproduce on Windows 11 x64 with v26.10.0 and v26.12.0 failed (details below).

Subsystem

http / buffer (V8 fast API call inside Buffer.byteLength, reached from _http_outgoing).

What steps will reproduce the bug?

There is no standalone minimal repro yet - this is the report of a real production abort with a complete V8 stack. The reproducing workload is a Vite dev server under sustained browser traffic:

  1. Run vite (8.3.4) on Linux with Node 26.10.0.
  2. Load a page that pulls a large pre-bundled dependency chunk. In this case node_modules/.vite/deps/lib-*.js is 17,416,067 bytes; Vite's send helper appends an inline source map, producing a String[43640789].
  3. Drive continuous Playwright traffic for roughly ten minutes (261 browser tests hitting the dev server).
  4. The dev-server process aborts and every later connection fails with net::ERR_CONNECTION_REFUSED.

The abort itself:

abort: Lazy deopt after a fast API call with return value is unsupported

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x7f49dce3ea76]
    1: byteLength [0x3fc66a4d8b91] [node:buffer:923] [bytecode=0xe4e3e6b3dc1 offset=88](this=0x3fc66a4d72e1 <JSFunction Buffer (sfi = 0x385470d41a39)>#0#,0x3ba819d309a1 <String[43640789]: uc"...<truncated>>">#1#,0x36331f5c0011 <undefined>)
    2: maybePrepareFinalChunk(aka maybePrepareFinalChunk) [0x67fc7c1ba61] [node:_http_outgoing:1069] [bytecode=0x1de7ebdcd5d1 offset=58](this=0x36331f5c0011 <undefined>,0x3ba819d357d9 <ServerResponse map = 0x25850d03f771>#2#,0x3ba819d309a1 <String[43640789]: uc"...<truncated>>">#1#,0x36331f5c0011 <undefined>)
    3: end [0x67fc7c1e8b9] [node:_http_outgoing:1197] [bytecode=0x1de7ebdcd0b1 offset=117](this=0x3ba819d357d9 <ServerResponse map = 0x25850d03f771>#2#,0x3ba819d309a1 <String[43640789]: uc"...<truncated>>">#1#,0x36331f5c0011 <undefined>,0x36331f5c0011 <undefined>)
    4: send$1(aka send$1) [0x1b9f12a631e9] [file:///home/runner/work/<repo>/node_modules/vite/dist/node/chunks/node.js:~17519] [pc=0x7f49bd3567a7](...)
    5: viteTransformMiddleware [file:///home/runner/work/<repo>/node_modules/vite/dist/node/chunks/node.js:~20159]

Frame 1 is Node's own Buffer.byteLength (node:buffer:923) and frame 2 is Node's maybePrepareFinalChunk (node:_http_outgoing:1069), whose source is captured in the report:

function maybePrepareFinalChunk(msg, chunk, encoding) {
  if (typeof chunk !== 'string' && !isUint8Array(chunk))
    return false;

  if (msg.destroyed || msg.strictContentLength)
    return false;

  if (!msg._header) {
    msg._contentLength = typeof chunk === 'string' ?
      Buffer.byteLength(chunk, encoding) : chunk.byteLength

So the aborting path is res.end(string) with msg._header unset, which calls Buffer.byteLength(hugeString, undefined).

How often does it reproduce? Is there a required condition?

Twice in two CI runs on Linux x64, roughly ten minutes into sustained dev-server traffic. It did not reproduce in short bursts.

I could not reproduce it locally on Windows 11 x64, with either v26.10.0 or v26.12.0, using:

  • 300 sequential res.end() responses of a 43.6 MB string;
  • 3,000 responses of a 1 MB string alternating with a Buffer and with res.end(string, 'utf8') to vary the call site;
  • 2,800 requests for the real 43.8 MB Vite dev-server chunk (the same send path as the crash) over keep-alive sockets;
  • the same runs with --deopt-every-n-times=3 to force deopts at deopt points.

So the trigger appears to need more than "a large string through res.end" - possibly the specific optimized-code state of the Vite middleware chain on the CI runner, or a longer warm-up than a few thousand requests.

What is the expected behavior? Why is that the expected behavior?

Serving a large string with res.end() should never abort the process. Payload size and repetition may cost memory and CPU, but a correct runtime either deoptimizes or keeps the optimized code; it does not terminate.

What do you see instead?

The process aborts with Lazy deopt after a fast API call with return value is unsupported, killing the server mid-suite.

Additional information

The fatal string is a V8 bailout reason, v8/src/codegen/bailout-reason.h:

"Lazy deopt after a fast API call with return value is unsupported"

and Buffer.byteLength is exactly a fast API call with a return value, per src/node_buffer.cc:

uint32_t FastByteLengthUtf8(...) {
TRACK_V8_FAST_API_CALL("Buffer::FastByteLengthUtf8");
static CFunction fast_byte_length_utf8(CFunction::Make(FastByteLengthUtf8));

The corresponding V8 work item is "Add deopt support after fast api calls with return values" (https://issues.chromium.org/issues/418936518), so this may be a V8 limitation that Node surfaces. Filing here because the aborting frame is Node's _http_outgoing code and the call is Node's own Buffer.byteLength, and because the practical fix may be on the Node side.

Our workaround, in case it is useful for triage, is to make the caller hand Node bytes so the fast API is not on the path (res.end(Buffer.from(content)) instead of res.end(content)); with that in place the dev server survives the same workload.

If a standalone reproduction is required before this is actionable, I am happy to run a loop on a Linux runner against a candidate commit - please say which shape you want (for example a node:test server plus a client loop, or a V8 d8 snippet) and I will provide it.

Vorherrschende Sprache
JavaScript
Sterne
123k
Forks
39.3k
Ø Merge
4 T. 12 Std.
Gemergte PRs (30 T.)
240

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus nodejs/node

Alle Issues in nodejs/node

Ähnliche Issues

Weitere Issues zu JavaScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.