No way to enable the default <worker_name>.<account_name>.workers.dev route in cloudflare_worker_script

[garysassano]

Description

Currently, the cloudflare_worker_script resource in the Terraform Cloudflare provider lacks the ability to enable the default route (<worker_name>.<subdomain>.workers.dev) upon deployment. This issue requests the addition of a property or mechanism to control the default route's activation state.

Terraform and Cloudflare Provider Versions

• Terraform: 1.8.2
• Cloudflare Provider: 4.30.0

Affected Resource

• cloudflare_worker_script

Steps to Reproduce

1. Deploy a cloudflare_worker_script resource.
2. Navigate to <worker_name> ➜ Settings ➜ Triggers in the Cloudflare dashboard.
3. Observe that the worker script is deployed, but the associated default route is disabled.
4. Confirm the absence of a property within the cloudflare_worker_script resource to enable the default route.

Expected Behavior

A new property or mechanism should be introduced to the cloudflare_worker_script resource, allowing users to specify whether the default route should be enabled or disabled upon deployment.

Actual Behavior

Currently, the default route remains disabled after deploying the worker script, and there's no option to control its state within the Terraform configuration.

Additional Context

While no official API exists for enabling the default route, the Wrangler CLI utilizes an undocumented API endpoint to achieve this.

This suggests that the Terraform provider could potentially implement similar functionality to enable the default route during worker script deployment.

Potential Implementation

One possible approach is to add a boolean attribute like enable_default_route to the resource. Setting it to true would activate the default route upon deployment.

resource "cloudflare_worker_script" "example" {
  # ... other configurations

  enable_default_route = true
}

Benefits

• Improved Automation: Eliminates the manual step of enabling the default route, allowing for fully automated worker deployments.
• Consistency: Aligns the Terraform provider's capabilities with the functionality available through the Wrangler CLI.

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[github-actions]

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.

This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

[jacobbednarz]

this is not a bug but an enhancement to a resource. please lodge this with customer support or your account team to have them escalate it to the respective service team.

duplicate of #2892, #1921 and #1013.

[garysassano]

How is it an enhancement to prevent users from correctly configuring their resources? You allow to do it in Wrangler but not in Terraform, so there's clearly something wrong.

[garysassano]

It's concerning that SST had to resort to examining Wrangler's source code to discover and utilize a shadow API for enabling the default route. Relying on such workarounds shouldn't be necessary, and Cloudflare should provide proper documentation and official support for this basic functionality.

[jacobbednarz]

it's an enhancement because the resource works, it is however missing a particular function of the service. there is work in progress to make this automatic (see https://blog.cloudflare.com/lessons-from-building-an-automated-sdk-pipeline) but for the mean time, it is a feature request to the service team to implement.

you can see the reasoning behind it not existing in the SDKs (and subsequently Terraform) at https://github.com/cloudflare/cloudflare-go/blob/master/docs/public-api-documentation.md#but-wranglercloudflaredother-project-doesnt-require-public-documentation.

i totally agree there is an issue here lacking coverage and no documentation for it but to address it, we need the service team to add the new feature which is not tracked in GitHub (until the automation is in place).