Provision validation: auto-namespace extension rule IDs and surface owning extension in report/telemetry
- Dominant language
- Go
- Stars
- 569
- Forks
- 364
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 136
Description
## Context
The provider-agnostic provision validation feature (#9019) lets extensions register validation checks with a `RuleId`. Today the rule-ID namespace is **global**: core enforces uniqueness on `check_type + rule_id` across *all* installed extensions (`internal/grpcserver/validation_service.go` `onRegisterRequest`), and the `RuleId`/`DiagnosticId` strings are the only thing that maps a finding back to its owning extension.
Core already knows the owning `extension.Id` at registration and dispatch time (`validationCheckEntry.Extension`), but it is **not** surfaced in:
- the preflight report (`pkg/output/ux/preflight_report.go`), or
- telemetry (`PreflightExtensionRulesKey` / `PreflightDiagnosticsKey` in `pkg/infra/provisioning/provision_validation.go`).
As a result, each extension must hand-roll an extension prefix in its rule ID to keep findings mappable. For example, `azure.ai.agents` now uses `azure.ai.agents.resource_group_location_mismatch` (see PR #9007), and the demo extension uses bare IDs like `demo_provision_warning`. This is inconsistent and easy to get wrong.
## Problem
When we add rule suppressions, rule sets, or per-extension enable/disable in the future, customers need a reliable way to map a rule to the extension that owns it. Relying on a hand-rolled string prefix convention is fragile and not enforced.
## Proposed options
1. **Auto-namespace rule IDs** — core prepends the owning `extension.Id` to the registered `RuleId` (e.g. `/` or `.`), so extensions register short, local IDs and the effective/global ID is derived consistently. Update the global-uniqueness check accordingly.
2. **Dedicated extension-id field** — carry `extension.Id` as a structured field alongside each finding in the preflight report and telemetry (`PreflightExtensionRulesKey`/`PreflightDiagnosticsKey`), so rules are mappable without string parsing.
3. Both (1) and (2).
Option 2 (or 3) is likely the most robust: a structured field avoids parsing and preserves the raw rule ID.
## Acceptance criteria
- A finding surfaced by an extension check can be unambiguously mapped to its owning extension id, without relying on a hand-rolled string convention.
- Telemetry records the owning extension id for each invoked rule / diagnostic.
- Existing extensions (demo, azure.ai.agents) continue to work; document the recommended rule-ID convention.
## References
- Feature: #9019 (provider-agnostic provision validation checks)
- Consumer / motivating review: #9007 (azure.ai.agents resource-group location check) — reviewer @tg-msft raised the global-rule-ID mapping concern.
Contributor guide
Assessment
This issue has not been assessed yet.