Repository navigation
fix: distinguish resource metadata from Azure Resource Health - #3513
MK (mathiaskoeppel) wants to merge 1 commit into
Conversation
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
@microsoft-github-policy-service agree |
|
Ready for review; the CLA check has passed. Could a maintainer review the current Resource Health API/permission guidance and the offline negative regression, and authorize any required Azure Pipelines runs? Local strict Vally static lint and patch checks passed. The full upstream behavioral Vally suite remains unexecuted, as documented in the PR; the separate dated Codex smoke comparison is supporting evidence only. |
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues block the Azure diagnostics guidance correction and accompanying regression case.
No open issues 🎉
What changed in this PR
Corrects Azure diagnostics guidance for #3512 by distinguishing resource configuration and provisioning metadata from Azure Resource Health availability and workload health.
Changes:
- Relabels
az resource showand replaces the health-check example with the current availability lookup usingaz rest. - Documents the required permission, supported-resource limits, and handling of missing or failed health queries.
- Adds one synthetic, offline regression case to the existing response-quality suite.
| File | Description |
|---|---|
plugins/azure-skills/skills/azure-diagnostics/SKILL.md |
Corrects Resource Health commands and explains availability evidence and limitations. |
evals/azure-skills/azure-diagnostics/response-quality.eval.yaml |
Adds a regression case rejecting provisioning success as proof of health. |
Review effort: Balanced
Description
Fixes #3512.
The diagnostics guide labels
az resource showas a Resource Health check, although it returns resource configuration/provisioning metadata. Relabel that inspection and replace the Resource Health CLI example with the current availability lookup usingaz rest.Document
Microsoft.ResourceHealth/AvailabilityStatuses/current/read, supported-resource applicability, and the distinction between platform availability and guest/application/dependency/end-to-end health. Missing status, unsupported resources, denied access, or a failed query must leave availability unestablished.Append one synthetic, offline negative regression to the existing response-quality suite. Descriptions, routing, version placeholders, unrelated diagnostics, and generated distribution files are unchanged.
References: current availability API, provider operations, supported-resource health checks.
Validation
Against upstream
5a37c9190a10e9b635f00085e263db7b22196139:git diff --checkpasses; changed files use LF.vally lint plugins/azure-skills/skills/azure-diagnostics --eval-spec evals/azure-skills/azure-diagnostics/response-quality.eval.yaml --strictpasses (skill 2/2 checks and eval schema).provisioningState: Succeededcriterion.Dated supporting evidence from November 11, 2026: one Codex CLI 0.167.1 explicit-guidance smoke run per version, with the same three synthetic cases and 16 assertions, scored installed guidance 15/16 and the prepared correction 16/16. The installed response supplied the scope-list permission instead of the current-resource permission. All three health-distinction cases passed in both runs. This is neither automatic skill-selection testing nor full Vally behavioral coverage.
The published guide retains that tested correction with one additional failure-handling sentence. The historical comparison was not rerun. No Azure query was executed.
Not run: full upstream behavioral Vally suite/custom Copilot executor and graders, build, or repository npm test/typecheck/lint scripts. Repository dependencies and Copilot execution setup were not established; no dependencies were acquired or external agent runtime invoked for this contribution.
Checklist
cd tests && npm test) — not run; see limits abovefix:)Related Issues
Fixes #3512