`azurerm_cdn_frontdoor_route` - make `cdn_frontdoor_origin_ids` field `optional` by WodansSon · Pull Request #29350 · hashicorp/terraform-provider-azurerm

WodansSon · 2025-04-16T07:23:21Z

Community Note

Please vote on this PR by adding a 👍 reaction to the original PR to help the community and maintainers prioritize for review
Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for PR followers and do not help prioritize for review

Description

In issue #29063 a community member raised an issue that:

You will have a diff on cdn_frontdoor_origin_ids, it set to null on import

While this is by design, some community members stated that they would prefer that the cdn_frontdoor_origin_ids field be deprecated in favor of a depends_on argument. This PR addresses both issues allowing for both, with the caveat that this may cause more issues moving forward due to community members personal preference. In the design of this resource exposing the cdn_frontdoor_origin_ids field was intentional, showing the relationship between the resources and allowing the Terraform core runtime to provision and destroy the resources in the correct order to avoid errors. With this change, while it will work, it puts that duty on the end user to ensure the correct order/relationship of the resources based on their personal preference (e.g., cdn_frontdoor_origin_ids or a depends_on argument).

PR Checklist

I have followed the guidelines in our Contributing Documentation.
I have checked to ensure there aren't other open Pull Requests for the same update/change.
I have checked if my changes close any open issues. If so please include appropriate closing keywords below.
I have updated/added Documentation as required written in a helpful and kind way to assist users that may be unfamiliar with the resource / data source.
I have used a meaningful PR title to help maintainers and other users understand this change and help prevent duplicate work.
For example: “resource_name_here - description of change e.g. adding property new_property_name_here”

Changes to existing Resource / Data Source

I have added an explanation of what my changes do and why I'd like you to include them (This may be covered by linking to an issue above, but may benefit from additional explanation).
I have written new tests for my resource or datasource changes & updated any relevant documentation.
I have successfully run tests with my changes locally. If not, please provide details on testing challenges that prevented you running the tests.
(For changes that include a state migration only). I have manually tested the migration path between relevant versions of the provider.

Testing

My submission includes Test coverage as described in the Contribution Guide and the tests pass. (if this is not possible for any reason, please include details of why you did or could not add test coverage)

Change Log

Below please provide what should go into the changelog (if anything) conforming to the Changelog Format documented here.

azurerm_cdn_frontdoor_route - make cdn_frontdoor_origin_ids field optional [GH-00000]

This is a (please select all that apply):

Bug Fix
New Feature (ie adding a service, resource, or data source)
Enhancement
Breaking Change

Related Issue(s)

Fixes #29063

Note

If this PR changes meaningfully during the course of review please update the title and description as required.

…r-azurerm into d_frontdoor_route

wyattfry

This may have already been considered, but I was thinking about how giving the route a property for origin IDs only reflects part of what's actually happening at the Azure API level. As it is probably known, routes don't depend on specific origins—they just need their associated origin group to have at least one enabled origin before creation of the route can succeed.

What if we handled the issue in the provider itself with a custom poller? It could catch the specific "origin group needs at least one enabled origin" error from Azure and retry route creation for a few minutes. The Portal does not allow for origin groups with zero enabled origins, but the REST API does, even though such groups are of no practical value. If an origin group exists, I believe it's safe to assume that soon it will have at least one enabled origin.

The poller approach would:

be more semantically accurate
remove the need for workarounds in user configurations
handle the timing automatically

The downside is a potential added delay during apply if origins aren't ready immediately, but that seems like a reasonable trade-off for cleaner resource modeling. Curious what others think about this approach, or if there are better alternatives, or reasons why the custom poller one wouldn't work?

wyattfry · 2025-08-20T14:23:34Z

Could you replace the utils.String() etc with pointer.To()?

wyattfry · 2025-08-20T15:27:45Z


 Manages a Front Door (standard/premium) Route.

+!>**Note:** The `azurerm_cdn_frontdoor_route` resource must **explicitly** reference its associated `azurerm_cdn_frontdoor_origin` resource(s). This can be achieved either by using a `depends_on` meta-argument that points to the `azurerm_cdn_frontdoor_origin` resource(s), or by specifying the `azurerm_cdn_frontdoor_origin` IDs via the `cdn_frontdoor_origin_ids` field.


Suggested change

!>**Note:** The `azurerm_cdn_frontdoor_route` resource must **explicitly** reference its associated `azurerm_cdn_frontdoor_origin` resource(s). This can be achieved either by using a `depends_on` meta-argument that points to the `azurerm_cdn_frontdoor_origin` resource(s), or by specifying the `azurerm_cdn_frontdoor_origin` IDs via the `cdn_frontdoor_origin_ids` field.

!> **Note:** The `azurerm_cdn_frontdoor_route` resource must **explicitly** reference its associated `azurerm_cdn_frontdoor_origin` resource(s). This can be achieved either by using a `depends_on` meta-argument that points to the `azurerm_cdn_frontdoor_origin` resource(s), or by specifying the `azurerm_cdn_frontdoor_origin` IDs via the `cdn_frontdoor_origin_ids` field.

wyattfry · 2025-08-20T16:01:02Z

+				Optional: true,

 				Elem: &pluginsdk.Schema{


I've seen both ways in the code, but it seems most of the time there's no new line before Elem:

Suggested change

Optional: true,

Elem: &pluginsdk.Schema{

Optional: true,

Elem: &pluginsdk.Schema{

WodansSon · 2025-08-22T06:16:16Z

This may have already been considered, but I was thinking about how giving the route a property for origin IDs only reflects part of what's actually happening at the Azure API level. As it is probably known, routes don't depend on specific origins—they just need their associated origin group to have at least one enabled origin before creation of the route can succeed.

What if we handled the issue in the provider itself with a custom poller? It could catch the specific "origin group needs at least one enabled origin" error from Azure and retry route creation for a few minutes. The Portal does not allow for origin groups with zero enabled origins, but the REST API does, even though such groups are of no practical value. If an origin group exists, I believe it's safe to assume that soon it will have at least one enabled origin.

The poller approach would:

be more semantically accurate

remove the need for workarounds in user configurations

handle the timing automatically

The downside is a potential added delay during apply if origins aren't ready immediately, but that seems like a reasonable trade-off for cleaner resource modeling. Curious what others think about this approach, or if there are better alternatives, or reasons why the custom poller one wouldn't work?

That would likely be a more modern solution to the API’s provisioning order issue for this resource, as it would let Terraform handle the behavior more gracefully rather than relying on faux fields. However, the custom poller wasn’t really an option when this resource/PR was first created. I agree the custom poller approach is worth considering going forward, but for the scope of this PR, can we set that aside? I’m happy to open a follow-up PR to introduce the custom poller. For now, can we move this PR forward to address the current customer needs without that added functionality?

wyattfry · 2025-08-25T17:38:21Z

This may have already been considered, but I was thinking about how giving the route a property for origin IDs only reflects part of what's actually happening at the Azure API level. As it is probably known, routes don't depend on specific origins—they just need their associated origin group to have at least one enabled origin before creation of the route can succeed.
What if we handled the issue in the provider itself with a custom poller? It could catch the specific "origin group needs at least one enabled origin" error from Azure and retry route creation for a few minutes. The Portal does not allow for origin groups with zero enabled origins, but the REST API does, even though such groups are of no practical value. If an origin group exists, I believe it's safe to assume that soon it will have at least one enabled origin.
The poller approach would:

be more semantically accurate

remove the need for workarounds in user configurations

handle the timing automatically

The downside is a potential added delay during apply if origins aren't ready immediately, but that seems like a reasonable trade-off for cleaner resource modeling. Curious what others think about this approach, or if there are better alternatives, or reasons why the custom poller one wouldn't work?

That would likely be a more modern solution to the API’s provisioning order issue for this resource, as it would let Terraform handle the behavior more gracefully rather than relying on faux fields. However, the custom poller wasn’t really an option when this resource/PR was first created. I agree the custom poller approach is worth considering going forward, but for the scope of this PR, can we set that aside? I’m happy to open a follow-up PR to introduce the custom poller. For now, can we move this PR forward to address the current customer needs without that added functionality?

Yes, the delay would be regrettable. I'm sorry to ask more of you, but from the user's perspective, I believe the improved experience a custom poller would provide would be worth the additional wait. Are there time-sensitive situations that would make the delay too costly?

wyattfry

Just a couple very small points.

wyattfry · 2025-08-22T16:21:10Z


 Manages a Front Door (standard/premium) Route.

+!> **Note:** The `azurerm_cdn_frontdoor_route` resource must **explicitly** reference its associated `azurerm_cdn_frontdoor_origin` resource(s). This can be achieved either by using a `depends_on` meta-argument that points to the `azurerm_cdn_frontdoor_origin` resource(s), or by specifying the `azurerm_cdn_frontdoor_origin` IDs via the `cdn_frontdoor_origin_ids` field.


We'd like to save the "!>" notes for cases where costly or irreversible damage could occur. The "~>" is a good choice for advising users how to avoid minor errors.

Suggested change

!> **Note:** The `azurerm_cdn_frontdoor_route` resource must **explicitly** reference its associated `azurerm_cdn_frontdoor_origin` resource(s). This can be achieved either by using a `depends_on` meta-argument that points to the `azurerm_cdn_frontdoor_origin` resource(s), or by specifying the `azurerm_cdn_frontdoor_origin` IDs via the `cdn_frontdoor_origin_ids` field.

~> **Note:** The `azurerm_cdn_frontdoor_route` resource must **explicitly** reference its associated `azurerm_cdn_frontdoor_origin` resource(s). This can be achieved either by using a `depends_on` meta-argument that points to the `azurerm_cdn_frontdoor_origin` resource(s), or by specifying the `azurerm_cdn_frontdoor_origin` IDs via the `cdn_frontdoor_origin_ids` field.

wyattfry · 2025-08-22T16:22:52Z

+~> **Note:** The `cdn_frontdoor_origin_ids` field is not sent to the Azure API, it exists solely to ensure Terraform can manage the correct `provisioning` and `destruction` order of related resources. When importing an existing `azurerm_cdn_frontdoor_route` resource, you will need to manually add the `cdn_frontdoor_origin_ids` field to your configuration after the resource has been successfully imported.
+
+~> **Note:** If the `cdn_frontdoor_origin_ids` field is not defined in the configuration, you **must** use a `depends_on` meta-argument that references the corresponding `azurerm_cdn_frontdoor_origin` resource(s) for the route. When importing an existing `azurerm_cdn_frontdoor_route` resource from Azure, you will need to manually add the `depends_on` meta-argument to your configuration after the resource has been successfully imported.


Could these two notes be condensed and combined?

…n_ids in azurerm_cdn_frontdoor_route documentation

catriona-m

Hi @WodansSon thanks for fixing this up. It looks like there are some conflicts needing resolved on this, but otherwise it looks like this is nearly ready to go. Thanks!

…r-azurerm into d_frontdoor_route

WodansSon · 2026-03-12T06:54:57Z

Hi @WodansSon thanks for fixing this up. It looks like there are some conflicts needing resolved on this, but otherwise it looks like this is nearly ready to go. Thanks!

Thanks for the calling that out, @catriona-m, I have fixed the conflicts and am running the tests again. 🙂

--- PASS: TestAccCdnFrontDoorRoute_complete (1606.21s)
--- PASS: TestAccCdnFrontDoorRoute_requiresImport (1611.69s)
--- PASS: TestAccCdnFrontDoorRoute_basic (1622.74s)
--- PASS: TestAccCdnFrontDoorRoute_basicDependsOnAndField (1629.25s)
--- PASS: TestAccCdnFrontDoorRoute_basicDependsOn (1696.55s)
--- PASS: TestAccCdnFrontDoorRoute_update (1746.74s)
--- PASS: TestAccCdnFrontDoorRoute_originPath (1752.09s)

WodansSon · 2026-03-12T08:19:13Z

Test after adding the depends_on step to update:

--- PASS: TestAccCdnFrontDoorRoute_update (1705.68s)

wuxu92 · 2026-04-09T07:02:51Z

A custom poller can mitigate the issue in creation, but there are two cases:

it's not 100% sure that "If an origin group exists, I believe it's safe to assume that soon it will have at least one enabled origin", as customer may only config origin group and route with no origin, then the poller won't work
the dependency issue still exists in delete. that means we still need a specific depends on to all managed origin resources.

I agree we should make cdn_frontdoor_origin_ids as optional and update the document to mitigate the import issue

sreallymatt

Thanks @WodansSon - LGTM ✅

stale

Initial Check-in...

f945592

WodansSon requested a review from a team as a code owner April 16, 2025 07:23

github-actions Bot added documentation service/cdn size/M enhancement labels Apr 16, 2025

Merge branch 'main' into d_frontdoor_route

21a0c11

github-actions Bot added the waiting-response label May 22, 2025

Merge branch 'main' of https://github.com/hashicorp/terraform-provide…

ee701b6

…r-azurerm into d_frontdoor_route

github-actions Bot removed the waiting-response label Jun 5, 2025

wyattfry self-assigned this Aug 20, 2025

wyattfry suggested changes Aug 20, 2025

View reviewed changes

github-actions Bot added the waiting-response label Aug 20, 2025

Address PR comments...

c6a2dc9

WodansSon requested a review from magodo as a code owner August 22, 2025 05:56

github-actions Bot removed the waiting-response label Aug 22, 2025

WodansSon added ai-assisted ai-assisted-review labels Aug 22, 2025

wyattfry previously requested changes Aug 26, 2025

View reviewed changes

github-actions Bot added the waiting-response label Aug 26, 2025

docs: update note formatting and clarify usage of cdn_frontdoor_origi…

ee787ef

…n_ids in azurerm_cdn_frontdoor_route documentation

github-actions Bot removed the waiting-response label Sep 3, 2025

catriona-m previously requested changes Oct 8, 2025

View reviewed changes

katbyte unassigned wyattfry Dec 1, 2025

sreallymatt added the waiting-response label Mar 11, 2026

WodansSon added 2 commits March 12, 2026 00:14

Merge branch 'main' of https://github.com/hashicorp/terraform-provide…

7d3e441

…r-azurerm into d_frontdoor_route

Fix conflict...

ada7a2e

github-actions Bot removed the waiting-response label Mar 12, 2026

github-actions Bot added the waiting-response label Mar 12, 2026

Fix lint error...

4fddb6e

github-actions Bot removed the waiting-response label Mar 12, 2026

Add updateDependsOn method for cdn_frontdoor_route tests

6ad761a

sreallymatt approved these changes Apr 10, 2026

View reviewed changes

sreallymatt merged commit 0247a1b into main Apr 10, 2026
49 checks passed

sreallymatt deleted the d_frontdoor_route branch April 10, 2026 14:52

github-actions Bot added this to the v4.69.0 milestone Apr 10, 2026


		Manages a Front Door (standard/premium) Route.

		!>Note: The `azurerm_cdn_frontdoor_route` resource must explicitly reference its associated `azurerm_cdn_frontdoor_origin` resource(s). This can be achieved either by using a `depends_on` meta-argument that points to the `azurerm_cdn_frontdoor_origin` resource(s), or by specifying the `azurerm_cdn_frontdoor_origin` IDs via the `cdn_frontdoor_origin_ids` field.

	!>Note: The `azurerm_cdn_frontdoor_route` resource must explicitly reference its associated `azurerm_cdn_frontdoor_origin` resource(s). This can be achieved either by using a `depends_on` meta-argument that points to the `azurerm_cdn_frontdoor_origin` resource(s), or by specifying the `azurerm_cdn_frontdoor_origin` IDs via the `cdn_frontdoor_origin_ids` field.
	!> Note: The `azurerm_cdn_frontdoor_route` resource must explicitly reference its associated `azurerm_cdn_frontdoor_origin` resource(s). This can be achieved either by using a `depends_on` meta-argument that points to the `azurerm_cdn_frontdoor_origin` resource(s), or by specifying the `azurerm_cdn_frontdoor_origin` IDs via the `cdn_frontdoor_origin_ids` field.

	!> Note: The `azurerm_cdn_frontdoor_route` resource must explicitly reference its associated `azurerm_cdn_frontdoor_origin` resource(s). This can be achieved either by using a `depends_on` meta-argument that points to the `azurerm_cdn_frontdoor_origin` resource(s), or by specifying the `azurerm_cdn_frontdoor_origin` IDs via the `cdn_frontdoor_origin_ids` field.
	~> Note: The `azurerm_cdn_frontdoor_route` resource must explicitly reference its associated `azurerm_cdn_frontdoor_origin` resource(s). This can be achieved either by using a `depends_on` meta-argument that points to the `azurerm_cdn_frontdoor_origin` resource(s), or by specifying the `azurerm_cdn_frontdoor_origin` IDs via the `cdn_frontdoor_origin_ids` field.

		~> Note: The `cdn_frontdoor_origin_ids` field is not sent to the Azure API, it exists solely to ensure Terraform can manage the correct `provisioning` and `destruction` order of related resources. When importing an existing `azurerm_cdn_frontdoor_route` resource, you will need to manually add the `cdn_frontdoor_origin_ids` field to your configuration after the resource has been successfully imported.

		~> Note: If the `cdn_frontdoor_origin_ids` field is not defined in the configuration, you must use a `depends_on` meta-argument that references the corresponding `azurerm_cdn_frontdoor_origin` resource(s) for the route. When importing an existing `azurerm_cdn_frontdoor_route` resource from Azure, you will need to manually add the `depends_on` meta-argument to your configuration after the resource has been successfully imported.

Conversation

WodansSon commented Apr 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Community Note

Description

PR Checklist

Changes to existing Resource / Data Source

Testing

Change Log

Related Issue(s)

Uh oh!

wyattfry left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WodansSon commented Aug 22, 2025

Uh oh!

wyattfry commented Aug 25, 2025

Uh oh!

wyattfry left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

catriona-m left a comment

Choose a reason for hiding this comment

Uh oh!

WodansSon commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

WodansSon commented Mar 12, 2026

Uh oh!

wuxu92 commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sreallymatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

WodansSon commented Apr 16, 2025 •

edited

Loading

wyattfry left a comment •

edited

Loading

wyattfry left a comment •

edited

Loading

WodansSon commented Mar 12, 2026 •

edited

Loading

wuxu92 commented Apr 9, 2026 •

edited

Loading