fix(SignalR): retry access token refresh on 401 in TS client

[daniloneto]

fix(SignalR): retry access token refresh on 401 in TS client

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Summary of the changes (Less than 80 chars)

Description

• Handle both HttpError.status and HttpResponse.statusCode
• Normalize string "401" to number before comparison
• Retry exactly once using _refreshTokenAndRetry
• Skip retry when token factory returns empty
• Preserve existing behavior for non-401 errors
• Add unit tests for 401 response, HttpError, string "401", no-retry cases

Fixes #56494

[dotnet-policy-service]

Thanks for your PR, @@daniloneto. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[Copilot]

Pull Request Overview

This PR fixes a bug in the SignalR TypeScript client where access token refresh wasn't being retried properly on 401 errors. The fix handles both HTTP response objects and thrown errors, normalizes string status codes to numbers, and ensures exactly one retry attempt when the access token factory is available.

• Adds robust 401 error detection for both HttpResponse and HttpError cases
• Normalizes string "401" status codes to number format for consistent comparison
• Implements exactly one retry attempt with proper token refresh logic

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/SignalR/clients/ts/signalr/src/AccessTokenHttpClient.ts	Core implementation with helper functions for status normalization and retry logic
src/SignalR/clients/ts/signalr/tests/AccessTokenHttpClient.test.ts	Comprehensive test coverage for all retry scenarios including edge cases

[daniloneto]

@dotnet-policy-service agree

[Copilot]

Pull Request Overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

[Copilot]

The condition request.abortSignal checks for the existence of the signal, not if it's been aborted. This should likely check request.abortSignal?.aborted to determine if the request was cancelled, or this logic may be incorrect for the intended behavior.

Suggested change

	if (request.abortSignal) return this._innerClient.send(request);
	if (request.abortSignal?.aborted) return this._innerClient.send(request);

[Copilot]

[nitpick] This complex conditional logic should be split into multiple lines for better readability. Consider using separate if-else blocks to make the authorization header logic clearer.

Suggested change

	if (this._accessToken) h.Authorization = 'Bearer ' + this._accessToken; else if (this._accessTokenFactory) delete h.Authorization;
	if (this._accessToken) {
	h.Authorization = 'Bearer ' + this._accessToken;
	} else if (this._accessTokenFactory) {
	delete h.Authorization;
	}

[Copilot]

The comment mentions 'allowRetry=false triggered by initial token acquisition above' but there's no token acquisition visible in this test method above this line. The comment appears to be inaccurate or misleading.

Suggested change

	const resp = await client.send(request); // send path with existing logic; allowRetry=false triggered by initial token acquisition above
	const resp = await client.send(request); // Verifies that allowRetry=false prevents retry on initial token acquisition (401 response).