BigQueryReadClient::ReadRows fails with UNKNOWN: Error occurred when fetching oauth2 token after CreateReadSession succeeds

[dharanad]

Client google-cloud-cpp v2.22.0

What Happened

Error Source: RUNTIME
Error Code: INVALID_STATE
Reason: BigQuery ReadRows failed for stream projects/rising-woods-374602/locations/us/sessions/CAISDG80QTJWdmc5UnpMSRoCamMaAm55/streams/CM8RGgJqYxoCbnkoAg: UNKNOWN: Error occurred when fetching oauth2 token. (rows delivered by this data source before the failure: 0)

I want to understand the failure mode here.

1. Under what conditions does this occur?
2. Is this a client side or service side issue ? how do I confirm which one it is?

Is UNKNOWN error type retried by the default BigQueryReadConnection retry policy? If a transient token fetch failure lands as UNKNOWN, it looks like it would bypass retry and kill the read outright. Is that expected, and is there a supported way to make token-fetch failures retryable ?

[hamedrabah]

This failure is happening on the client side, before the BigQuery Storage service sees the ReadRows RPC. In v2.22.0, BigQueryReadAuthDecorator::ReadRows calls auth_->ConfigureContext(*context); a token-fetch failure is returned as a streaming RPC error before the child client is invoked.

The default BigQuery Read retry traits only retry UNAVAILABLE, so an UNKNOWN status from credential acquisition is treated as permanent. I would check which ADC source the process selected, then test connectivity from that same process/container to its token source (metadata server or OAuth endpoint), including DNS, proxy, CA bundle, and clock.

I would also upgrade from v2.22.0 before adding custom policy. A custom BigQueryReadRetryPolicyOption can retry this narrowly, but treating every UNKNOWN as transient is risky. If you add an outer retry, limit it to establishing the stream before any row has been delivered.