Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#13,093 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@mvanhorn já está trabalhando nisso.

Desde 9/10/2026.

  • #13106 de @mvanhorn — aberto

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
android, java
Domínio
backend-api-design

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
Java
Estrelas
12.1k
Forks
4k
Merge médio
2d 9h
PRs com merge (30d)
44

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de grpc/grpc-java

Todas as issues de grpc/grpc-java

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.