Add resource group location mismatch preflight check (azure.ai.agents)#9007
Add resource group location mismatch preflight check (azure.ai.agents)#9007vhvb1989 wants to merge 1 commit into
Conversation
Adds a local-preflight validation check to the azure.ai.agents extension that detects an immutable resource-group region conflict before provisioning. When the target resource group already exists in a different region than AZURE_LOCATION, the subscription-scoped Bicep deployment fails with the ARM error "InvalidResourceGroupLocation" (the #1 production error). This check surfaces the conflict during azd's validation phase with a clear message and remediation guidance instead of a slow deploy-time failure. Registered via the extension WithValidationCheck capability (RuleID resource_group_location_mismatch, severity Error). The check is best-effort: it skips silently on missing env values, auth failures, a 404 (resource group not created yet), or any API error. Fixes #9006 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
vhvb1989
requested review from
JeffreyCA,
glharper,
huimiu,
hund030,
therealjohn,
trangevi and
trrwilson
as code owners
📋 Prioritization NoteThanks for the contribution! The linked issue isn't in the current milestone yet. |
There was a problem hiding this comment.
Pull request overview
Adds a best-effort local-preflight validation check to the azure.ai.agents extension that detects an immutable resource-group region conflict before provisioning. When the target resource group already exists in a region different from AZURE_LOCATION, ARM would fail a subscription-scoped deployment with InvalidResourceGroupLocation; this check surfaces a blocking error with remediation guidance during azd's validation phase instead. The check is wired via the extension WithValidationCheck capability, mirroring the existing demo-extension pattern, and is non-blocking on any resolution/auth/API failure (only a definitive mismatch blocks).
Changes:
- New
ResourceGroupLocationCheckimplementingazdext.ValidationCheckProvider, resolving env values + credential and comparing the existing RG region againstAZURE_LOCATION(case-insensitive). - Registered the check in
listen.gowithCheckType: local-preflight,RuleID: resource_group_location_mismatch. - Unit tests for the pure comparison/message logic (
evaluateResourceGroupLocation).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
cli/azd/extensions/azure.ai.agents/internal/project/resource_group_location_check.go |
New check: reads env/context values, resolves credential, GETs the RG, and emits a blocking mismatch result with remediation guidance. |
cli/azd/extensions/azure.ai.agents/internal/project/resource_group_location_check_test.go |
Table-style unit tests covering matching (incl. case-insensitive) and mismatching regions and the message/suggestion content. |
cli/azd/extensions/azure.ai.agents/internal/cmd/listen.go |
Registers the new validation check with the extension host. |
| resourceGroup := envValue(ctx, envClient, envName, "AZURE_RESOURCE_GROUP") | ||
| if resourceGroup == "" { | ||
| // Mirror azd's default when AZURE_RESOURCE_GROUP is unset. | ||
| resourceGroup = fmt.Sprintf("rg-%s", envName) |
| if err != nil { | ||
| return "" | ||
| } | ||
| return resp.Value |
There was a problem hiding this comment.
The check logic is solid: best-effort/non-blocking pattern is correct, credential handling follows the established LookupTenant pattern used across the extension, and the pure-function separation makes the comparison testable without Azure access.
Two minor items already noted by the bot: reusing defaultResourceGroupName instead of the inline fmt.Sprintf keeps the fallback in sync with provisioning, and trimming in the package-level envValue would prevent a false-positive block if a value has stray whitespace.
|
Is it possible to do a quick evaluation of why this might be happening? Adding this preflight check doesn't actually get rid of the error, it just moves it. We should try and figure out what is actually causing this mismatch, and if there's something we can do to prevent it at the beginning. |
It looks like this could happen for more than one single reason: #9006 |
What
Adds a local-preflight validation check to the
azure.ai.agentsextension that detects an immutable resource-group region conflict before provisioning and stopsazdwith a clear note + remediation suggestion.This is the #1 production ARM error (
InvalidResourceGroupLocation, 87 operations in the top-5 report): a subscription-scoped Bicep deployment fails because the target resource group already exists in a different region thanAZURE_LOCATION. A resource group's region cannot be changed, so proceeding is a guaranteed failure — the check is a blocking Error, surfaced duringazd's validation phase instead of at deploy time.How
internal/project/resource_group_location_check.go—ResourceGroupLocationCheckimplementingazdext.ValidationCheckProvider.internal/cmd/listen.govia the extensionWithValidationCheckcapability (CheckType: local-preflight,RuleID: resource_group_location_mismatch), matching the demo extension pattern.AZURE_LOCATION(prefersValidationContext.EnvLocation()),AZURE_SUBSCRIPTION_ID,AZURE_RESOURCE_GROUP(fallbackrg-{env}); resolves credential viaLookupTenant→AzureDeveloperCLICredential;GETs the resource group and compares regions (case-insensitive).What the user sees
…with a suggestion offering 3 remediation paths (
azd env set AZURE_LOCATION, a different resource group, oraz group delete).Testing
go build,go test ./internal/project ./internal/cmd,go vet,golangci-lint(0 issues),gofmt, cspell — all pass. Repro steps to seeazdstop with the note + suggestion are in the linked issue.Fixes #9006
Part of #9005