.NET: Fix flaky declarative test

[peibekwe]

Motivation and Context

Move from unauthenticated GitHub rest API for the HttpRequestAction integration test to avoid random 429s that break CI pipelines. Changed to authenticated ARM APIs to consistently verify the action tests.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the Contribution Guidelines
• All unit tests pass, and I have added new tests where possible
• Is this a breaking change? If yes, add "[BREAKING]" prefix to the title of the PR.

[github-actions]

Automated Code Review

Reviewers: 4 | Confidence: 84%

✓ Correctness

The PR correctly migrates the integration test from an unauthenticated GitHub API to an authenticated Azure ARM endpoint. All API contracts (constructor signatures, property types, disposal patterns) are verified correct against the source. The authentication flow, HTTP client lifetime management, and assertion logic are all sound.

✓ Security Reliability

This PR replaces an unauthenticated GitHub API call with an authenticated Azure ARM endpoint for integration testing. The implementation is sound from a security/reliability perspective: token acquisition uses the standard Azure SDK AzureCliCredential, the bearer token is only attached to requests matching the ARM URL prefix, resource disposal follows correct LIFO ordering (authenticatedClient outlives the handler), and no secrets are hardcoded in source. The httpClientProvider pattern is well-documented and the handler correctly does not dispose provider-returned clients.

✓ Test Coverage

The PR correctly replaces a flaky unauthenticated GitHub API test with an authenticated Azure ARM test. The test assertions are meaningful — verifying workflow events emitted and that the response is a parseable, non-empty GUID. The httpClientProvider integration with DefaultHttpRequestHandler is correctly used per its constructor contract. One minor assertion quality issue: discarding TryParse's return value produces a less helpful failure message when the response isn't a valid GUID.

✓ Design Approach

The main design issue is that the new HttpRequestAction integration test now depends on live Azure ARM tenant-list access, which is a broader environment/RBAC requirement than the rest of this workflow suite and is not necessary to validate the HttpRequestAction plumbing itself. I did not find other design-approach problems that met the evidence bar.

---

Automated review by peibekwe's agents

[Copilot]

Pull request overview

This PR updates the declarative workflow integration test for HttpRequestAction to avoid flaky unauthenticated GitHub REST calls (and resulting 429s) by switching the test to an authenticated Azure ARM endpoint, with the bearer token injected via a custom HttpClient from the test harness.

Changes:

• Updated the HttpRequest.yaml workflow to call https://management.azure.com/tenants and surface a tenantId.
• Updated the integration test to acquire an ARM token via Azure CLI credentials and route ARM requests through an authenticated HttpClient.
• Adjusted assertions to validate the returned tenantId is a non-empty GUID rather than checking GitHub repo visibility.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
dotnet/tests/Microsoft.Agents.AI.Workflows.Declarative.IntegrationTests/Workflows/HttpRequest.yaml	Switches the workflow’s HTTP call from GitHub API to authenticated ARM tenants endpoint and outputs a tenantId.
dotnet/tests/Microsoft.Agents.AI.Workflows.Declarative.IntegrationTests/InvokeToolWorkflowTest.cs	Adds ARM token acquisition + authenticated HttpClient routing, and updates test assertions accordingly.

[github-actions]

Automated Code Review

Reviewers: 4 | Confidence: 91% | Result: All clear

Reviewed: Correctness, Security Reliability, Test Coverage, Design Approach

---

Automated review by peibekwe's agents