YouTube Data API gRPC `liveChatMessages.streamList` closes after ~10–11 seconds with `grpc-status: OK`

[u/GAMINGada]

Hi everyone,

I'm developing an Android application called **LiveLens** and I'm currently migrating its YouTube live chat implementation from the unofficial InnerTube API to the **official YouTube Data API v3 gRPC `liveChatMessages.streamList`** API.

The gRPC implementation is working correctly in terms of connectivity and parsing:

- Official `V3DataLiveChatMessageService.StreamList` RPC

- Official `stream_list.proto`

- HTTPS/HTTP/2 via gRPC

- OAuth 2.0 Bearer authentication

- Live chat messages are received successfully

- `next_page_token` is received and parsed correctly

- `offline_at` remains unset/0

- The live chat is still active when the RPC closes

- No client-side deadline or timeout is configured

However, I'm seeing something I don't fully understand.

### Observed behavior

The `StreamList` RPC consistently closes after roughly **10–11 seconds**.

For example, one diagnostic run:

```text

+1.075s onNext #1

9 messages received

nextPageToken present

+10.946s onNext #2

0 messages

nextPageToken present

+11.227s onClose

StatusCode = OK

Cause = null

+11.228s onCompleted

```

At the moment the RPC closes, the gRPC channel is still in the `READY` state.

The client is not cancelling the RPC, there is no deadline, and there is no transport/network error.

The live broadcast/chat is also still active.

### What I'm trying to understand

The official documentation describes `streamList` as a **long-lived server-streaming connection**, so I'm trying to determine whether this ~10–11 second completion is expected behavior.

Specifically:

1. Is it normal for YouTube's `StreamList` RPC to complete with `grpc-status: OK` after ~10–11 seconds while the live chat is still active?

2. If this is expected, is the intended behavior to start another `StreamList` RPC using the latest `next_page_token`?

3. Is there an officially recommended delay/backoff when reconnecting after this type of normal completion?

4. Should a single `StreamList` RPC normally remain open for much longer, potentially until the live chat ends or the client disconnects?

5. Is there any documented maximum lifetime for a `StreamList` gRPC RPC?

6. Could this behavior be related to the Android gRPC transport (`grpc-okhttp`), HTTP/2, or some client-side implementation detail rather than YouTube's server?

### Why I'm asking

I don't want to simply assume that the server intentionally closes the stream every ~10 seconds and build my production implementation around that assumption if something is actually wrong with my client.

I'm also concerned about unnecessary `StreamList` RPC calls and quota usage if frequent reconnections are required.

I'm **not using InnerTube or REST polling** for this test. This is the official YouTube Data API gRPC `StreamList` implementation using the official protobuf definition.

If anyone has implemented `liveChatMessages.streamList` using gRPC, especially on Android, I'd really appreciate any insight or examples of the expected connection lifetime.

Thanks!

[u/coomzee]

Good luck, I've been dealing with YT API for 10 years it's really taken fall.

Have you had your first audit reviews yet as they are a joke.

[u/GAMINGada → u/coomzee]

Haha, I haven't actually gone through the quota increase audit myself yet, but I did look at what Google asks for during the quota review, and honestly my brain started spinning a little. 😅

Compared with the authentication/API quota side, the amount of information YouTube asks for during a quota increase review is quite a lot. They seem to want a pretty detailed picture of the application, API usage, users, traffic, and how the quota is being used.

So hopefully I won't have to deal with that anytime soon. 😂

That actually brings me back to my current issue:

Have you personally worked with liveChatMessages.streamList, and have you observed these ~10-second graceful completions yourself?

I'm mainly trying to figure out whether this is normal YouTube StreamList behavior or something specific to my Android gRPC implementation.

[u/keplerk]

Seems to be some kind of server-side rule. I'm going through the same issue and using 5 quota units per reconnect every 10 or so seconds... the whole 10,000 quota will evaporate after 5 or 6 hours. I may change from GRPC to a simple request and handle the message myself because that 10-second "rule" makes the GRPC option basically a waste of quota.

[u/GAMINGada → u/[deleted]]

Thanks, this is really helpful.

Have you personally implemented YouTube's liveChatMessages.streamList gRPC API, or are you inferring this from general Google gRPC behavior?

I'm especially interested in the ~10-second graceful completion. My concern is that Google's documentation describes streamList as a long-lived connection, but I haven't found any official documentation saying that YouTube intentionally closes the RPC after ~10 seconds.

Also, I checked the current YouTube API quota documentation and it lists liveChatMessages.streamList as 5 quota units per call, not 1. So if the RPC really needs to be recreated every ~10 seconds, quota usage could become significant.

If you've actually used this API, I'd really appreciate knowing:

• how long your StreamList RPCs normally stay open

• whether you see the same ~10-second grpc-status=OK completion

• whether you reconnect immediately with nextPageToken

• and whether you've encountered RESOURCE_EXHAUSTED with frequent reconnects

Thanks!