-
Notifications
You must be signed in to change notification settings - Fork 10k
changelog: add Workers Terraform, API, and Smart Placement fixes #22149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
29 changes: 29 additions & 0 deletions
29
src/content/changelog/fundamentals/2025-03-21-resource-force-replacement-bug.mdx
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,29 @@ | ||
| --- | ||
| title: Dozens of Cloudflare Terraform Provider resources now have proper drift detection | ||
| description: Improper drift detection in the Cloudflare Terraform Provider resulted in dozens of resources always indicating they needed to be updated or replaced. | ||
| products: | ||
| - fundamentals | ||
| date: 2025-03-21T00:00:00Z | ||
| --- | ||
|
|
||
| In [Cloudflare Terraform Provider](https://github.com/cloudflare/terraform-provider-cloudflare) versions 5.2.0 and above, dozens of resources now have proper drift detection. Before this fix, these resources would indicate they needed to be updated or replaced — even if there was no real change. Now, you can rely on your `terraform plan` to only show what resources are expected to change. | ||
|
|
||
| This issue affected [resources](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs) related to these products and features: | ||
|
|
||
| - API Shield | ||
| - Argo Smart Routing | ||
| - Argo Tiered Caching | ||
| - Bot Management | ||
| - BYOIP | ||
| - D1 | ||
| - DNS | ||
| - Email Routing | ||
| - Hyperdrive | ||
| - Observatory | ||
| - Pages | ||
| - R2 | ||
| - Rules | ||
| - SSL/TLS | ||
| - Waiting Room | ||
| - Workers | ||
| - Zero Trust | ||
23 changes: 23 additions & 0 deletions
23
src/content/changelog/fundamentals/2025-03-21-sensitive-values-redacted.mdx
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,23 @@ | ||
| --- | ||
| title: Cloudflare Terraform Provider now properly redacts sensitive values | ||
| description: Resources in the Cloudflare Terraform Provider that have sensitive properties will not show those values in logs. | ||
| products: | ||
| - fundamentals | ||
| date: 2025-03-21T00:00:00Z | ||
| --- | ||
|
|
||
| In the [Cloudflare Terraform Provider](https://github.com/cloudflare/terraform-provider-cloudflare) versions 5.2.0 and above, sensitive properties of resources are redacted in logs. Sensitive properties in [Cloudflare's OpenAPI Schema](https://raw.githubusercontent.com/cloudflare/api-schemas/refs/heads/main/openapi.yaml) are now annotated with `x-sensitive: true`. This results in proper auto-generation of the corresponding Terraform resources, and prevents sensitive values from being shown when you run Terraform commands. | ||
|
|
||
| This issue affected [resources](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs) related to these products and features: | ||
|
|
||
| - Alerts and Audit Logs | ||
| - Device API | ||
| - DLP | ||
| - DNS | ||
| - Magic Visibility | ||
| - Magic WAN | ||
| - TLS Certs and Hostnames | ||
| - Tunnels | ||
| - Turnstile | ||
| - Workers | ||
| - Zaraz |
14 changes: 14 additions & 0 deletions
14
src/content/changelog/workers/2025-03-22-smart-placement-stablization.mdx
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| --- | ||
| title: Smart Placement is smarter about running Workers and Pages Functions in the best locations | ||
| description: Workers and Pages Functions with Smart Placement enabled will not unexpectedly return to default locations if request traffic dips. | ||
| products: | ||
| - workers | ||
| - pages | ||
| date: 2025-03-22T00:00:00Z | ||
| --- | ||
|
|
||
| [Smart Placement](/workers/configuration/smart-placement/) is a unique Cloudflare feature that can make decisions to move your Worker to run in a more optimal location (such as closer to a database). Instead of always running in the default location (the one closest to where the request is received), Smart Placement uses certain “heuristics” (rules and thresholds) to decide if a different location might be faster or more efficient. | ||
|
|
||
| Previously, if these heuristics weren't consistently met, your Worker would revert to running in the default location—even after it had been optimally placed. This meant that if your Worker received minimal traffic for a period of time, the system would reset to the default location, rather than remaining in the optimal one. | ||
|
|
||
| Now, once Smart Placement has identified and assigned an optimal location, temporarily dropping below the heuristic thresholds will not force a return to default locations. For example in the previous algorithm, a drop in requests for a few days might return to default locations and heuristics would have to be met again. This was problematic for workloads that made requests to a geographically located resource every few days or longer. In this scenario, your Worker would never get placed optimally. This is no longer the case. |
60 changes: 60 additions & 0 deletions
60
src/content/changelog/workers/2025-04-15-workers-api-fixes.mdx
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,60 @@ | ||
| --- | ||
| title: Fixed and documented Workers Routes and Secrets API | ||
| description: The Workers Routes API now returns a correct response and the Secrets API has been added to the Cloudflare API docs. | ||
| products: | ||
| - workers | ||
| - workers-for-platforms | ||
| date: 2025-04-15T00:00:00Z | ||
| --- | ||
|
|
||
| ## Workers Routes API | ||
|
|
||
| Previously, a request to the Workers [Create Route API](/api/resources/workers/subresources/routes/methods/create/) always returned `null` for "script" and an empty string for "pattern" even if the request was successful. | ||
|
|
||
| ```bash title="Example request" | ||
| curl https://api.cloudflare.com/client/v4/zones/$CF_ACCOUNT_ID/workers/routes \ | ||
| -X PUT \ | ||
| -H "Authorization: Bearer $CF_API_TOKEN" \ | ||
| -H 'Content-Type: application/json' \ | ||
| --data '{ "pattern": "example.com/*", "script": "hello-world-script" }' | ||
| ``` | ||
|
|
||
| ```json title="Example bad response" | ||
| { | ||
| "result": { | ||
| "id": "bf153a27ba2b464bb9f04dcf75de1ef9", | ||
| "pattern": "", | ||
| "script": null, | ||
| "request_limit_fail_open": false | ||
| }, | ||
| "success": true, | ||
| "errors": [], | ||
| "messages": [] | ||
| } | ||
| ``` | ||
|
|
||
| Now, it properly returns all values! | ||
|
|
||
| ```json title="Example good response" | ||
| { | ||
| "result": { | ||
| "id": "bf153a27ba2b464bb9f04dcf75de1ef9", | ||
| "pattern": "example.com/*", | ||
| "script": "hello-world-script", | ||
| "request_limit_fail_open": false | ||
| }, | ||
| "success": true, | ||
| "errors": [], | ||
| "messages": [] | ||
| } | ||
| ``` | ||
|
|
||
| ## Workers Secrets API | ||
|
|
||
| The [Workers](/api/resources/workers/subresources/scripts/subresources/secrets/) and [Workers for Platforms](/api/resources/workers_for_platforms/subresources/dispatch/subresources/namespaces/subresources/scripts/subresources/secrets/) secrets APIs are now properly documented in the Cloudflare OpenAPI docs. Previously, these endpoints were not publicly documented, leaving users confused on how to directly manage their secrets via the API. Now, you can find the proper endpoints in our public documentation, as well as in our API Library SDKs such as [cloudflare-typescript](https://github.com/cloudflare/cloudflare-typescript) (>4.2.0) and [cloudflare-python](https://github.com/cloudflare/cloudflare-python) (>4.1.0). | ||
|
|
||
| Note the `cloudflare_workers_secret` and `cloudflare_workers_for_platforms_script_secret` [Terraform resources](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs) are being removed in a future release. This resource is not recommended for managing secrets. Users should instead use the: | ||
|
|
||
| - [Secrets Store](/api/resources/secrets_store/) with the "Secrets Store Secret" binding on Workers and Workers for Platforms Script Upload | ||
| - "Secret Text" Binding on [Workers Script Upload](/api/resources/workers/subresources/scripts/methods/update/) and [Workers for Platforms Script Upload](/api/resources/workers_for_platforms/subresources/dispatch/subresources/namespaces/subresources/scripts/methods/update/) | ||
| - Workers (and WFP) Secrets API |
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.
Uh oh!
There was an error while loading. Please reload this page.