Brett Willis
CDCloudflare Developers
•Created by Brett Willis on 1/29/2025 in #workers-help
~5% of our workers requests never return from Cloudflare after the worker returns
We recently migrated our production API backend onto Workers compute and now ~5% of requests never get a response. E.g. in devtools the requests remain pending forever (i.e. several minutes until I get bored), with no headers or status code received. Experiencing the issue across all browsers and client apps.
When I encounter it on my machine I am able to identify these requests in workers observability logs, and they appear as successful response i.e.
outcome: "ok" and $cloudflare.event.response.status: 200 but they remain hanging and never return from Cloudflare's edge.
How can the response remain hanging in Cloudflare after the worker returns?? What mechanisms could be at play here?
Can someone give me tips on how to debug this? Can I give some Ray IDs or worker/account IDs to the team to investigate?
This ~5% failure rate on our API is causing frustration for our users and customers, so any urgent tips/ideas/support would be greatly appreciated 🙏33 replies
CDCloudflare Developers
•Created by Brett Willis on 5/16/2024 in #workers-help
Smart Placement "too smart"?
The docs https://developers.cloudflare.com/workers/configuration/smart-placement/#unsupported-back-end-services mention that smart placement is not supported for globally distributed services, and specifically mentions Google APIs.
If I'm connecting to a Cloud Firestore database in a specific region via the Cloud Firestore REST API, will smart placement ignore this? The Firestore database is always located in a specific region.
Also based on the following:
If your Worker does less than one subrequest on average, Smart Placement will run the Worker at the data center closest to the user.Any application has some routes that require multiple round trips to a database, and some routes that do not touch a database (may serve from cache etc, or reach other backends in different regions). Depending on varying usage statistics, what if the routes that do not hit the database have higher usage than the routes that do hit the database... will this cause Smart Placement to run the worker at a data centre that is far from the database, causing a big latency hit for those routes that have multiple round trips to the database? And this could change any day depending on usage statistics of different routes? As a developer I'm wondering if smart placement would be too smart for it's own good. I know where my backend services are located and I'd prefer to tell Workers where to run rather than wondering how request statistics might be affecting the application latency. I'd prefer to say "just locate the Worker here, or fall back to nearby region if that region is down".
3 replies