CompressionFilter’s IdentityHandler.writeMessage calls Buffer-only .copy() on caller-provided message
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 82/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Tranquilo
- Stack tecnológico
- node.js, typescript
Línea de trabajo
Empieza en packages/grpc-js/src/compression-filter.ts, en IdentityHandler.writeMessage, y reproduce el fallo con un requestSerialize personalizado que devuelva un Uint8Array. Verifica que la misma ruta acepte mensajes tanto Uint8Array como Buffer sin el TypeError y produzca un resultado o estado RPC significativo.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem description
CompressionFilter's IdentityHandler.writeMessage (packages/grpc-js/src/compression-filter.ts) calls message.copy(output, 5), which is a Buffer-only method:
async writeMessage(message, compress) {
const output = Buffer.allocUnsafe(message.length + 5);
output.writeUInt8(0, 0);
output.writeUInt32BE(message.length, 1);
message.copy(output, 5); // ← Buffer-only
return output;
}
Uint8Array.prototype.copy is undefined. If the caller-provided request serializer produces a Uint8Array rather than a Buffer, this throws TypeError: message.copy is not a function. The thrown error then propagates as a code: undefined, details: undefined, empty-Metadata gRPC status (the empty-status side is tracked separately: https://github.com/grpc/grpc-node/issues/3051).
Uint8Array request serializers are reachable in practice via protobufjs, which falls back to Uint8Array-returning Writer.alloc whenever protobufjs.util.Buffer is unset. One concrete trigger is the @protobufjs/[email protected] regression — see protobufjs/protobuf.js#2214 — where bundlers (Turbopack, certain webpack configurations) statically rewrite the new dynamic require(name) to throw MODULE_NOT_FOUND, leaving util.Buffer = null in any bundled server build.
Reproduction steps
In a Next.js 16 application with output: "standalone" (Turbopack):
- Add
@google-cloud/[email protected]and use it from a Server Component (any call works:collection(...).get(),doc(...).get(), etc.). - Ensure
@protobufjs/inquireresolves to1.1.1(the default with[email protected]+). next buildand run the standalone output. Trigger any Firestore call.
Expected: the call succeeds or fails with a meaningful status.
Actual: the call's callback receives Error: undefined undefined: undefined with { code: undefined, details: undefined, metadata: Metadata { internalRepr: Map(0) {}, options: {} } }. Running with GRPC_TRACE=all GRPC_VERBOSITY=DEBUG shows cancelWithStatus code: undefined details: "undefined" firing within 1 ms of write() called with message of length N.
Independent of protobufjs, the same path is reachable by registering a custom method whose requestSerialize returns new Uint8Array([...]) and calling client.makeUnaryRequest(...).
Environment
- OS: macOS 15.6 arm64 (local repro); Linux amd64 (Google Cloud Run production)
- Node: v24
- Node installation: project
engines.node = "24", npm 11 - Package:
@grpc/[email protected] - Adjacent:
[email protected],@google-cloud/[email protected],@grpc/[email protected], Next.js 16.2.6 with Turbopack
Additional context
Suggested fix: output.set(message, 5) in place of message.copy(output, 5). Buffer extends Uint8Array and both expose .set, so the call works for either input.
Impact in our deployment: a Dependabot bump to [email protected] (which pulls @protobufjs/[email protected] transitively) caused this TypeError on every Firestore call. Under google-gax retry the undefined code is treated as retryable, so the call retries for the gax budget before bubbling up. For server-streaming RPCs under additional SDK-level retry (Firestore's QueryUtil._stream), every request hangs for ~45 s and then 500s. We hit a production outage before identifying the underlying chain.
- Lenguaje dominante
- TypeScript
- Estrellas
- 4.8k
- Forks
- 716
- Merge medio
- 2 d 3 h
- PR fusionados (30 d)
- 10
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de grpc/grpc-node
-
package: @grpc/grpc-js
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
grpc/grpc-node#2993 · 3 comentarios · 4 reacciones ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
grpc/grpc-node#3091 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
feature request
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
grpc/grpc-node#3077 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 76/100
grpc/grpc-node#3068 · 2 comentarios · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Upgrade to protobufjs version 8Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
grpc/grpc-node#3062 · 2 comentarios · 1 reacción ·
Los mantenedores suelen responder en 1 día
Todos los issues de grpc/grpc-node
Issues similares
-
bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
StabilityNexus/Fate-EVM-Frontend#153 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
code-yeongyu/oh-my-openagent#9039 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Tencent/teamai-cli#862 ·
Los mantenedores suelen responder en 1 día
-
bug good first issue hacktoberfest redis
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
libredb/libredb-studio#1164 ·
Los mantenedores suelen responder en 1 día
-
flake
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
coder/xum#4920 · 2 comentarios ·
Los mantenedores suelen responder en 1 día