grpc / grpc/grpc-java

cronet: when trailers are missing, gRPC reuses the headers

Open
#12,642 6 comments 0 reactions 1 assignee Claimed by @kannanjgithub View on GitHub
android bug
Dominant language
Java
Stars
12.1k
Forks
4k
Avg merge
2d 17h
Merged PRs (30d)
37

Description

### What version of gRPC-Java are you using?

1.78.0

### What is your environment?

Server: Cloudflare with HTTP/3 enabled
Client: Android 16 / gRPC with `CronetChannelBuilder`

### What did you expect to see?

gRPC works properly.

### What did you see instead?

gRPC fails with the following exception.
```
io.grpc.StatusException: UNKNOWN: missing GRPC status in response
at io.grpc.Status.asException(Status.java:547)
at io.grpc.kotlin.ClientCalls$rpcImpl$1$1$1.onClose(ClientCalls.kt:264)
at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:566)
at io.grpc.internal.ClientCallImpl.access$100(ClientCallImpl.java:72)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInternal(ClientCallImpl.java:734)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:715)
at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:133)
at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:124)
at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:89)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:586)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:820)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:717)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:704)
```
This issue doesn't always happen, and when I logged the protocols of the requests (`RequestFinishedInfo.getResponseInfo().getNegotiatedProtocol()`) by `CronetEngine.addRequestFinishedListener()`, I found that all the successful request were using `h2` protocol, and all the failed requests were using `quic/1+spdy/3`.

### Steps to reproduce the bug

Use `CronetChannelBuilder` to request a backend with QUIC enabled.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.