Local preflight: warn users when bicep snapshot fails and checks are skipped
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
Research direction
Start at the local preflight path that runs bicep snapshot and inspect the existing log.Printf handling for snapshot failures. Add a debug-visible explanation that preflight checks were skipped, then verify that it appears with --debug while normal output remains unchanged.
Written by the indexing model from the issue text.
Description
Problem
When bicep snapshot fails (e.g., due to templates using non-null assertions ! on module outputs that cannot be speculatively evaluated), all local preflight checks are silently skipped. Users have no visibility that the AI quota check and other preflight validations did not run.
The current code logs the failure at log.Printf level which only shows with --debug, but there is no user-facing indication that checks were skipped.
Root Cause
The Bicep snapshot engine speculatively evaluates template expressions. When a template uses patterns like:
principalId: myModule.outputs.systemAssignedMIPrincipalId!
The ! (non-null assertion) fails at snapshot time because module outputs are unknown before deployment. This causes bicep snapshot to exit with:
Template snapshotting could not be completed for the following reason:
'The provided value for the template parameter ... is not valid.
A non-null value for the property 'principalId' must be provided'
This is tracked upstream as Azure/bicep#18822 (still open).
Expected Behavior
- When
bicep snapshotfails, show a debug-level log message explaining that preflight checks could not be performed for the template - The message should be visible when
--debugis set but not clutter normal output - Consider including guidance about the upstream limitation
Related
- Upstream: Azure/bicep#18822
- Investigation: #7986
- Dominant language
- Go
- Stars
- 569
- Forks
- 365
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 132
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/azure-dev
-
area/extensions
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
area/ux bug customer-reported ext-agents
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
-
area/docs engineering item ext-agents test automation
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
enhancement ext-agents
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
priority: p3
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
googleapis/librarian#7636 ·