Genesys Cloud Node SDK: Access token expires mid-batch during bulk interaction updates

We’re running a batch job to update interaction metadata for about 5,000 records using the genesys-cloud-node-sdk (version 3.12). The script works fine for the first 1,000 or so items, then starts failing with 401s. It’s happening consistently around the 35-minute mark, which lines up with the access token expiration.

The SDK is supposed to handle token refresh automatically via the auth module, but it seems to be dropping the ball when the requests are queued up in the batch loop. I’ve tried using the Auth class to get a new token explicitly, but by the time the refresh completes, the pending requests in the loop have already failed.

Here’s the core loop:

const { Auth } = require('@gencloudsdk/platform-client');
const { ConversationApi } = require('@gencloudsdk/platform-client');

const auth = new Auth({
 clientId: process.env.CLIENT_ID,
 clientSecret: process.env.CLIENT_SECRET,
 serverUrl: process.env.SERVER_URL
});

const conversationApi = new ConversationApi();

async function updateBatch(ids) {
 // Get initial token
 const token = await auth.getAccessToken();
 console.log('Token expires at:', new Date(token.expires_in * 1000 + Date.now()));

 for (const id of ids) {
 try {
 // This call fails with 401 after ~35 mins
 await conversationApi.postConversationInteractions({
 conversationId: id,
 body: { type: 'note', text: 'Updated by batch' }
 });
 } catch (error) {
 if (error.code === 401) {
 console.error('Auth failed for ID:', id);
 // Attempting manual refresh here
 const newToken = await auth.getAccessToken();
 console.log('Refreshed token:', newToken.expires_in);
 // But the current request is already dead
 break;
 }
 throw error;
 }
 }
}

The postConversationInteractions call throws a 401. I tried catching the 401 and calling auth.getAccessToken() again, but the SDK instance seems to hold onto the old token for the active request context.

Is there a way to force the SDK to re-authenticate before each batch chunk? Or do I need to implement a retry wrapper that catches the 401, waits for the refresh, and then retries the specific failed request? The Auth class has a setAccessToken method, but it’s not clear if that updates the internal state for the API clients.

Also, we’re running this in an AWS Lambda us-west-2. The environment variables are set correctly, and single-request calls work fine. It’s only the batch volume that triggers the expiry issue.

Any pointers on how to structure the retry logic so it doesn’t just break the whole batch?