fix(auth): cap 401 retry count in refreshAccessToken

[cs-raj]

Problem

refreshAccessToken's 401 branch recursed with the same stale error object and an unincremented counter:

const refreshed = await this.refreshToken(hostName);
if (refreshed) {
  return this.refreshAccessToken(error, maxRetryCount); // counter never advances
}

The maxRetryCount cap existed only on the 429/408 branch, so nothing terminated the 401 path. A refresh that succeeded without clearing the 401 looped forever, issuing a real refresh-endpoint call on every pass.

This is the v1 counterpart of the v2 fix, which was never backported. v1-legacy's copy of the file was byte-identical to main's pre-fix version, so the change applies exactly as it did there.

Fix

Apply the same guard the 429/408 branch already uses — one refresh attempt, then a clear error and exit:

case 401:
  if (maxRetryCount >= 2) {
    const errorDetails = formatError(error);
    ux.print(`Authentication failed after token refresh: ${errorDetails}`, { color: 'red' });
    return;
  }
  ...
  if (refreshed) {
    return this.refreshAccessToken(error, maxRetryCount + 1);
  }

The cap is 2 rather than the 429/408 branch's 3 because one refresh is enough to establish the token is dead. The resulting file is byte-identical to the version on main.

Reachability

Worth a reviewer's attention, because it is subtle. The callers in @contentstack/cli-variants (personalization-api-adapter.ts:311, variant-api-adapter.ts:336) pass an HttpResponse, and APIResponse is typed { status, data } with no response field — which suggests the guard error.response?.status could never pass.

It does pass. HttpResponse declares private readonly response: AxiosResponse and assigns it in the constructor; TypeScript's private is erased at compile time, so .response is a real own property at runtime. The branch is genuinely reachable — just via accidental coupling to an erased-private field. Not changed here, but worth knowing.

Tests

Adds test/unit/authentication-handler.test.ts — the first coverage for this file in either branch (the v2 fix shipped without tests). Eight cases:

401 handling

• stops after a single refresh when the 401 persists ← the regression guard
• does not retry when the refresh itself fails
• derives the host from a non-URL region cma
• does not attempt a refresh when no region cma is configured
• honours an already-exhausted retry count without refreshing

Other statuses

• no-op when the error carries no response
• no-op for an unhandled status
• still caps 429 retries at three attempts (guards the untouched branch)

The regression guard was verified to actually catch the bug: with the source fix reverted, the suite hangs indefinitely and has to be killed. With the fix, all 8 pass in ~2s.

Verification

• 8/8 new tests pass
• contentstack-utilities suite: 114 passing
• Full repo suite: 253 passing, 0 failures (utilities 114, auth 42, config 89, contentstack 8)
• pnpm build passes
• Talisman and Snyk pass

Notes

• Targets DX-23-09-2026-Release rather than v1-legacy, so merging does not trigger the release workflow. Pairs with fix(deps): declare tslib as a runtime dependency #2724 and fix(deps): declare tslib as a runtime dependency cli-plugins#370.
• Source change is confined to one file; cli-plugins is not affected.
• Out of scope, noted for follow-up: compareOAuthExpiry(true) at auth-handler.ts:391-393 skips the isRefreshingToken guard. It self-limits at two levels so it is not a live bug, but it is why each loop iteration hit the real refresh endpoint.

🤖 Generated with Claude Code

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	1	0	10	✅ Passed
🟠 High Severity	0	169	25	✅ Passed
🟡 Medium Severity	67	71	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

⚠️ Warning: The following vulnerabilities have exceeded their SLA thresholds (days since publication).

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	1	90 / 365 days	⚠️ Warning
🔵 Low	0	0	180 / 365 days	✅ Passed

ℹ️ Vulnerabilities Without Available Fixes (Informational Only)

The following vulnerabilities were detected but do not have fixes available (no upgrade or patch). These are excluded from failure thresholds:

• Critical without fixes: 0
• High without fixes: 169
• Medium without fixes: 71
• Low without fixes: 0

⚠️ BUILD PASSED WITH WARNINGS - SLA breaches detected for issues without available fixes

Consider reviewing these vulnerabilities when fixes become available.