Go gRPC service fails mid-batch due to OAuth token expiration during high-throughput analytics export

Could someone explain the correct pattern for handling access token refresh in a high-throughput Go gRPC microservice that processes Genesys Cloud events?

I am building a service in Asia/Singapore (SGT) that ingests webhook events and triggers batch analytics queries. The service uses the Genesys Cloud Go SDK. I have configured a Client Credentials flow for authentication. The initial token acquisition works perfectly. However, my batch jobs process thousands of records. The default access token lifetime is one hour. When a batch job runs for longer than 50 minutes, the subsequent API calls fail with a 401 Unauthorized error because the token expires mid-execution.

My current logic fetches a new token only at service startup. This is clearly insufficient for long-running batches. I need a robust retry mechanism that automatically refreshes the token when a 401 is received, without dropping the entire batch.

Here is my current YAML configuration for the OAuth client:

auth:
 client_id: "my-client-id"
 client_secret: "my-client-secret"
 scope: "analytics:export:read"
 base_url: "https://api.mypurecloud.com"
 token_cache_ttl: 3600 # 1 hour

In my Go code, I am wrapping the SDK client. When I receive a 401 from /api/v2/analytics/conversations/queries, I want to trigger a refresh. Should I implement a custom HTTP RoundTripper that intercepts 401s and calls /api/v2/oauth/token? Or does the Genesys Go SDK have a built-in token refresh handler I am missing?

I have tried manually calling the token endpoint on error, but race conditions occur when multiple gRPC handlers try to refresh the token simultaneously. I need a thread-safe solution. Any code examples or architectural advice for implementing a token refresh middleware in this context would be appreciated.