[Change Safety] Az.Cdn: opt-in + fix dynamicparam forwarding for custom-fronted profile cmdlets - #29999
Draft
YangAn-microsoft wants to merge 10 commits into
Draft
[Change Safety] Az.Cdn: opt-in + fix dynamicparam forwarding for custom-fronted profile cmdlets#29999YangAn-microsoft wants to merge 10 commits into
YangAn-microsoft wants to merge 10 commits into
Conversation
…ile cmdlets Regenerated Az.Cdn with the autorest.powershell generator fix (see Azure/autorest.powershell#1555): the outer proxy for custom-fronted write cmdlets (New/Remove/Update-Az{,FrontDoor}CdnProfile) now forwards the wrapped custom function's dynamicparam block, so -AcquirePolicyToken and -ChangeReference actually bind on these commands. Previously they were rejected with 'A parameter cannot be found that matches parameter name AcquirePolicyToken', even though the module was already opted into enable-change-safety. Live-validated: New-AzFrontDoorCdnProfile -AcquirePolicyToken now successfully creates a profile in a real subscription.
Contributor
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Contributor
|
Azure Pipelines: Successfully started running 1 pipeline(s). There may be pipelines that require an authorized user to comment /azp run to run. |
Member
|
/azp run |
Contributor
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
The manual regeneration used to apply the change-safety dynamicparam fix
pointed -ExamplesFolder at generated/Cdn/Cdn.Autorest/examples, which
does not exist (the real, hand-maintained example .md files live at
src/Cdn/Cdn.Autorest/examples). Export-ProxyCmdlet found no matching
example for any cmdlet and fell back to the '{{ Add code here }}'
placeholder in every exported cmdlet's comment-based help. Re-ran the
regeneration with the correct examples path to restore the real
examples; the change-safety dynamicparam fix is unaffected.
Member
|
/azp run |
Contributor
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
YangAn-microsoft
marked this pull request as draft
August 13, 2026 03:44
The bare autorest run in the earlier regeneration (68ff900) reset src/Cdn/Cdn.Autorest/Properties/AssemblyInfo.cs's AssemblyVersion/ AssemblyFileVersion from the real released 6.0.2 to AutoRest's default placeholder 0.1.0.0. The generated/ copy (the one actually compiled into the shipped Az.Cdn.private.dll) was unaffected and still correctly says 6.0.2; this only restores the stray src/ copy so it doesn't poison a future regeneration cycle.
The regeneration used the local autorest.powershell generator (via a directory junction into the AutoRest extension cache) instead of the officially published @autorest/powershell@4.0.754 npm package that CI uses. The generator embeds its own source file path into a diagnostic comment (a limitation note about deserializeFromResponse and headers), so this comment picked up my local dev machine's absolute path instead of the original CI path. Purely cosmetic/non-functional; reverted to keep the diff free of unrelated, machine-specific noise.
Member
|
/azp run |
Contributor
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
…dlet New-AzFrontDoorCdnRuleSet has no custom/*.ps1 front, so its dynamicparam forwarding was already working before this PR's fix (only the custom-fronted profile cmdlets were broken). Adding this scenario alongside the existing custom-fronted ones gives explicit regression coverage for both code paths going forward. Live-validated: created a real Front Door rule set end-to-end with -AcquirePolicyToken in the BAMI tenant.
Member
|
/azp run |
Contributor
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
Member
|
/azp run |
Contributor
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
YangAn-microsoft
marked this pull request as ready for review
August 13, 2026 05:42
Contributor
|
Azure Pipelines: Successfully started running 1 pipeline(s). There may be pipelines that require an authorized user to comment /azp run to run. |
… cmdlets, not just profile cmdlets
Member
|
/azp run |
Contributor
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
…(matches Aks/ContainerRegistry/EventHub/ServiceBus)
Member
|
/azp run |
Contributor
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
…dn migration/route/sku cmdlets
Member
|
/azp run |
Contributor
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
Yabo Hu (VeryEarly)
marked this pull request as draft
August 13, 2026 09:34
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Opts Az.Cdn into Change Safety (
-AcquirePolicyToken/-ChangeReference) and fixes a generator gap that prevented these parameters from binding on the custom-fronted CDN/AFD profile cmdlets.What's included
enable-change-safety: trueopt-in for the Cdn AutoRest project (profiles + AFD endpoints).dynamicparamblocks on the 6 custom-fronted profile cmdlets (New/Remove/Update-Az{,FrontDoor}CdnProfile) forwarding the wrapped private cmdlet's dynamic parameters.-AcquirePolicyTokenbefore ever dispatching to the custom function.src/Cdn/LiveTests/Cdn.Autorest/TestLiveScenarios.ps1) for both custom-fronted cmdlets (New-AzCdnProfile,New-AzFrontDoorCdnProfile) and generated, non-custom-fronted cmdlets (New-AzFrontDoorCdnEndpoint,New-AzFrontDoorCdnRuleSet), so a regression in either code path is caught going forward.Validation — live test evidence
Tested against a real Azure subscription (
f758ac53-3e63-4317-a956-0997793808d7, tenant4f00b3b6-2940-4f2c-b037-94637c180d30) — not mocked/recorded.New-AzFrontDoorCdnEndpoint -AcquirePolicyToken(generated cmdlet) — passed before this fix.New-AzFrontDoorCdnProfile -AcquirePolicyToken(custom-fronted cmdlet) — failed before this fix, passes after.Before the fix:
Confirmed root cause — the outer public proxy had no
dynamicparamblock at all:After the fix (rebuilt
Az.Cdn.private.dllwith the generator change, regeneratedexports/*.ps1):The profile was created successfully end-to-end, confirming
-AcquirePolicyTokennow binds and the change-safety token acquisition path executes.Deeper verification — proof the token acquisition pipeline actually fired
Binding the parameter and getting a successful create doesn't, by itself, prove ARM ever received the policy token — the write could succeed either way on a subscription that doesn't mandate it. For AutoRest-generated cmdlets this pipeline hook (
ContextAdapter.AddChangeSafetyPolicyTokenHandler) has no built-in-Debugobservability (unlike the SDK/RM cmdlet path), so a temporary, env-var-gated trace was added toPolicyTokenAcquirer.StampPolicyTokenAsync's call site (reverted afterward, verified via cleangit status) to get definitive proof:This confirms: the outgoing
PUTwas intercepted, a realPOSTto ARM'sacquirePolicyTokenendpoint was made and returned200 OK, the token was stamped onto the request as thex-ms-policy-external-evaluationsheader, and the subsequent async-pollGETwas correctly skipped by the write-verb gate.Additional live test — generated (non-custom-fronted) cmdlet
The scenarios above cover the two custom-fronted profile cmdlets. To also verify the code path that was never broken (plain generated cmdlets, which already had working dynamicparam forwarding before this PR), added and live-tested a new scenario against
New-AzFrontDoorCdnRuleSet— a fully generated cmdlet with nocustom/*.ps1front:This gives explicit regression coverage for both the custom-fronted path (fixed by this PR) and the plain-generated path (already correct), so a future change that breaks either one will be caught by
TestLiveScenarios.ps1.Generator fix: Azure/autorest.powershell#1555