Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#66,870 6 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, node.js
Área
backend, networking

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
JavaScript
Estrellas
123k
Forks
39.3k
Merge medio
4 d 11 h
PR fusionados (30 d)
237

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nodejs/node

Todos los issues de nodejs/node

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.