Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#13,093 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@mvanhorn y travaille déjà.

Depuis le 9/10/2026.

  • #13106 par @mvanhorn — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
android, java
Domaine
backend-api-design

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Java
Étoiles
12.1k
Forks
4k
Merge moyen
1 j 23 h
PR mergées (30 j)
44

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de grpc/grpc-java

Toutes les issues de grpc/grpc-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.