Token renewal sends old authorization header on retry, no retry limit (RSA4b, RSC10)

[paddybyers]

Spec points

• RSA4b: When a REST request fails with a token error (40140–40149), the library should obtain a new token and retry the request with the new token. Renewal should retry at most once per request.
• RSC10: "Transparent retry after token renewal."

Observed behaviour

Two compounding bugs in Resource.do():

1. Old authorization header sent on retry

After a token error, the retry calls:

await client.auth.authorize(null, null);
return withAuthDetails(client, headers, params, doRequest);

The headers parameter is the merged headers from the first withAuthDetails call, which already contains authorization: 'Bearer <old-token>'. Then withAuthDetails does Utils.mixin(newAuthHeaders, oldMergedHeaders), which overwrites the new token's authorization header with the old one.

2. No retry limit

The retry loop in Resource.do() is unbounded — on each token error, it calls authorize() and retries recursively with no counter. Combined with bug #1, this causes an infinite loop and eventual OOM when the server persistently returns token errors.

Failing tests (3)

Test	Issue
RSA4b - renewal on 40142 error	Retried request has old token in authorization header
RSC10 - transparent retry after renewal	Same: retried request carries old token
RSA4b - renewal limit	Unbounded retries (test caps authCallback at 3 to prevent OOM)

Reproduction

RUN_DEVIATIONS=1 npx mocha --grep "RSA4b|RSC10" test/uts/rest/auth/token_renewal.test.ts

From PR #2191, branch uts-rest.

┆Issue is synchronized with this Jira Task by Unito

[SimonWoolf]

Good catch. It never used to, looks like a regression from 601ebfe which added a variable shadowing bug