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

binder: RuntimeException during outbound serialization leaks the call and never notifies the peer

Abierto
  • ¿Algo no está bien?
#13,093 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@mvanhorn ya está trabajando en esto.

Desde el 9/10/2026.

  • #13106 de @mvanhorn — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
android, java
Área
backend-api-design

Línea de trabajo

Start with Outbound.sendInternal() and trace its callers in MultiMessageClientStream, SingleMessageClientStream, MultiMessageServerStream, and SingleMessageServerStream; inspect the listed start, half-close, headers, and close entry points. Compare their exception handling with writeMessage() and the core marshaller guards. Add coverage for the throwing-metadata reproductions on both client and server; done means failures close the call with non-OK status, release transport resources, and do not escape.

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

Descripción

bug
What version of gRPC-Java are you using?

1.85.0-SNAPSHOT

What is your environment?

Android

What did you expect to see?

When serializing outbound metadata or a message throws an unchecked exception from a binder stream method, the stream should end deterministically, the same way it does when writeMessage() throws:

  • the peer receives a close for that callId (so it fails immediately instead of waiting out its deadline);
  • the local ClientCall.Listener.onClose() / ServerCall.Listener.onCancel() runs with a non-OK status, and the application is not told the RPC completed successfully;
  • the call is removed from the transport's ongoingCalls (and the in-use count decremented) so graceful shutdown() can finish;
  • The unchecked exception does not escape to the caller.

ClientCallImpl.sendMessageInternal() and ServerCallImpl.sendMessageInternal() already catch RuntimeException from marshallers and cancel the stream; the four entry points below should behave the same.

What did you see instead?

grpc-binder serializes headers, messages and trailers lazily inside Outbound.sendInternal(). That method may call into user-supplied code (Parcelable.writeToParcel(), Metadata.BinaryStreamMarshaller.toStream(), InputStream.read()/close() on marshaller streams) but only catches IOException; every caller above it (Outbound.send(), the four *ClientStream/*ServerStream classes, Inbound.onTransportReady()) only catches StatusException. An unchecked exception escapes the transport entirely from four entry points that core does not guard:

Entry point Core caller Guarded by core?
MultiMessageClientStream.start() (writes request headers) ClientCallImpl.startInternal() → stream.start() No
SingleMessageClientStream.halfClose() (writes headers + the single request + half-close) ClientCallImpl.halfCloseInternal() No
MultiMessageServerStream.writeHeaders() ServerCallImpl.sendHeadersInternal() No
SingleMessageServerStream.close() / MultiMessageServerStream.close() (writes headers, pending message, status + trailers) ServerCallImpl.closeInternal() No

(For unary calls writeMessage() only stashes pendingSingleMessage; all serialization, including of the message, happens in halfClose()/close(), outside core's sendMessage() guard.)

Steps to reproduce the bug

Common fixture:

// A Parcelable whose writeToParcel() always throws.
static final class ThrowingParcelable implements Parcelable {
  @Override public void writeToParcel(Parcel parcel, int flags) {
    throw new IllegalStateException("writeToParcel() failed");
  }
  // describeContents()/CREATOR omitted
}
static final Metadata.Key<ThrowingParcelable> POISON_KEY =
    ParcelableUtils.metadataKey("poison-bin", ThrowingParcelable.CREATOR);

Server side:

  1. Register a unary echo method (ServerCalls.asyncUnaryCall) wrapped in a ServerInterceptor whose SimpleForwardingServerCall.close() does trailers.put(POISON_KEY, ne w ThrowingParcelable()) before delegating, and a second interceptor that records whether the app Listener gets onComplete() or onCancel().
  2. From the client, ClientCalls.futureUnaryCall(channel.newCall(METHOD, CallOptions.DEFAULT.withDeadlineAfter(2, SECONDS)), Empty.getDefaultInstance()).get(10, SECONDS).
  3. Assert the status is not DEADLINE_EXCEEDED → fails (it is DEADLINE_EXCEEDED).
  4. Assert the recorded server listener outcome is onCancel → fails (it is onComplete).
  5. server.shutdown(); assertTrue(server.awaitTermination(10, SECONDS)) → fails.

Stack of the escaping exception: ServerCalls$ServerCallStreamObserverImpl.onCompleted → ServerCallImpl.close → SingleMessageServerStream.close → ServerOutbound.sendSingleMessageAndClose → Outbound.send → Outbound.sendInternal → ServerOutbound.writeSuffix → MetadataHelper.writeMetadata → ParcelableInputStream.writeToParcel, surfacing in JumpToApplicationThreadServerStreamListener$HalfClosed.runInContext.

Client side:

  1. Complete one clean unary RPC on the channel first, so the binder transport is READY and the next start() reaches the binder stream synchronously (otherwise DelayedClientTransport defers it to the app executor and the exception surfaces there instead).
  2. Wrap the channel with a ClientInterceptor whose SimpleForwardingClientCall.start() does headers.put(POISON_KEY, new ThrowingParcelable()), and newCall() a BIDI_STREAMING method with withDeadlineAfter(2, SECONDS).
  3. call.start(listener, new Metadata()). Assert it does not throw → fails (IllegalStateException: writeToParcel() failed).
  4. Assert listener.onClose() is invoked within 10 s → fails (TimeoutException; the deadline never fires).
  5. channel.shutdown(); assertTrue(channel.awaitTermination(10, SECONDS)) → fails.
Lenguaje dominante
Java
Estrellas
12.1k
Forks
4k
Merge medio
2 d 6 h
PR fusionados (30 d)
26

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 grpc/grpc-java

Todos los issues de grpc/grpc-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.