Optimize Token Fetch calls across multiple CosmosClient connections

[ajchalla]

I have a couple of questions about token caching when creating the CosmosClient within our service. In our case, we use the token credential to create the CosmosClient and we connect with 50-60 accounts per DC, so that would the number of CosmosClient instances we would have.

Questions,

• Can the same token be used to connect with multiple cosmosdb accounts, if the appId and the tenantId is the same for token fetching?
• Is there any token caching that CosmosClient does that extends to creation of new cosmosclients (to different accounts) within the same appId, tenantId scope?
• If we would like to use the same token to connect to multiple accounts, what's the best way to go about it?

To clarify, we are looking to optimize on the calls to AAD to fetch the token.

[kirankumarkolli]

TokenReqeustContext Cosmos SDK uses is for scope https://{endpointUri.Host}/.default
In-case multiple-CosmosClients are created for different accounts then the token will be different for each account.

Token caching:

• SDK will not call TokenCredential for every request.
• The token will be cached inside, SDK and refreshes will be attempted with-in token-lifetime to proactively refresh
  • Default policy: first attempt after 50% lifetime, like 50%, 75%, 87.5% etc...
  • Application can override it with CosmosClientOptions.TokenCredentialBackgroundRefreshInterval (fixed and not-dynamic)

[ajchalla]

Couple more quick questions,

For the CosmosClient setup with AAD token Auth,

1. When does the token fetch happen? During the client initialization or on first request?

2. If CosmosClient sees a 429 from AAD on token fetch, what is the behavior? Is is retried and if it doesn't succeed what exception is returned back on the call to initialize the CosmosClient?

[kirankumarkolli]

Client initialization: Will do service interaction asynchronously (even with-out API invocation), which will needs the AAD token.

429 from AAD:

• TokenCrendetial implementation do handle 429 and retry it-self internally.
• CosmosClient
  • Post client initialization: As discussed above CosmosClient will attempt multiple times before current token expiry. Assuming that tokens are not really shortlived then it will have good number of retires to succeed.
  • CosmosClient initialization: Failure to get token will impact the CosmosClient initialization and start-up, though it will get retried.