Still getting AggregateErrors after applying all the magic

[sandorvasas]

We are still occasionally and nowadays more frequently getting AggregateErrors from the xero api. xero-node is v4.11.3. Connections to all of our client accounts usually break when we get those.

1. Since xero-node is built on the openid-client but did not / do not support setting a timeout,
   we increased the openid timeout and clock tolerance in our Docker container with a script as a post-processing step.
   RUN sed -i "s/timeout: 2500/timeout: 20000/g" /code/node_modules/openid-client/lib/helpers/request.js
   RUN sed -i "s/this.openIdClient[openid_client_1.custom.clock_tolerance] = 5;/this.openIdClient[openid_client_1.custom.clock_tolerance] = 100;/" /code/node_modules/xero-node/dist/XeroClient.js
   We're also setting Xero.XeroClient() constructor's httpTimeout to 20000.

2. We avoid creating many Xero.XeroClients using the singleton pattern, but we do create one XeroClient for each of the Xero Accounts we access.

3. We lock each Xero client while an operation is being executed.
   To make 2. and 3. clear, for example when two of our clients Alice and Bob who have different Xero Accounts want to query their list of xero items, there will be two Xero.XeroClients running the query at the same time. However, if Candice, who is also in Bob's Xero Account wants to query something else, the XeroClient running Bob's query will be locked until Bob's query finishes, then it runs Candice's query.
   So instead of having a single "über" XeroClient for all XeroAccounts and locking that (it would be too slow), we have a XeroClient per Xero Account and locking those. Not sure if this way of having XeroClients is still prone to the AggregateError -- the singleton pattern was proposed by a GitHub user to this specific error.

4. Tokens for the accounts are renewed sequentially.

Can you please take a closer look or suggest any solution?

[sandorvasas]

After discussion with Xero API support, it looks like we were hitting the 5 concurrent rate limit because we needed to fetch quotes by quoteIDs and (with getInvoices, one can provide an array of invoiceIDs, for getQuotes that is not supported) we have to pull quotes one-by-one. We just temporarily disabled that, so it's still unknown how we'll be able to pull the quotes we want without pulling a huge bunch of other quotes, but the random connection breaks seem to be resolved for now.

Xero API errors are very human unfriendly. "AggregateError" does not describe anything and leaves the tedious guesswork to the developer. For a more complex application that is receiving stochastic errors, it is basically impossible to find the error without Xero API support's in-depth help.