It's more that you are(hopefully) using the R2 bindings in Workers, which aren't subject to the same
It's more that you are(hopefully) using the R2 bindings in Workers, which aren't subject to the same(if any) rate-limiting
HThat should apply even if you use
workers.dev
DI am using the bindings, alright, I'll tag you when I have a few logs.
Thi guys, has anyone tried yugabyte db with cf workers? Is its performance better than D1 or PlanetScale? Since D1 does not handle table altering and typing really well, D1 also does not have local backup (although the alpha backend had it) and can't natively integrate with external service so I'm considering switching to MySQL and Postgres
DSo, if I make the requests on their own they don't exceed the cpu time, which is the error thrown (which is set at 5kms for this testing). When I am making the requests in batches of 20 or more though, then the requests towards the end start failing. They should have their own 5kms limit though as they are new requests which they don't even come close to.
Below are some examples from various logs:
Same images, just another request
Below are some examples from various logs:
Same images, just another request
DIs there a limit somewhere that I need to update?
UI don’t think those specific limits will be changed tbh
SHey, is there a recommended way to protect workers with api keys? I'm fairly new to API gateways as a whole and saw that cloudflare offers an API gateway through shield, but it's only available to enterprise clients
Was wondering if there was a way to setup a separate worker to act as a proxy and for handling api key management while storing the api keys in KV storage
Was wondering if there was a way to setup a separate worker to act as a proxy and for handling api key management while storing the api keys in KV storage
SAlso came across this post on reddit that talked about how to implement just that, but it goes really in depth
https://www.reddit.com/r/CloudFlare/comments/194r1kx/cloudflare_worker_review_api_key_service/
https://www.reddit.com/r/CloudFlare/comments/194r1kx/cloudflare_worker_review_api_key_service/
Reddit
Explore this post and more from the CloudFlare community
Xthanks
Xwow
KDon't know if it is a better fit here or in #r2: I noticed that one of my workers started to throw errors since 2023-12-24. What I figuered out is that out of nowhere the R2 binding to this worker does not work anymore. It is a binding to a EU-jurisdiction bucket. I've not touched the bucket or worker prior to today for 2 months.
The binding is still visible in the UI but I get
Is this a known issue or something that has changed in the workers platform I did not notice?
The binding is still visible in the UI but I get
The specified bucket does not exist. (Code: 10006)Is this a known issue or something that has changed in the workers platform I did not notice?
CHave you raised this on community forums? Or first time
KNo I haven't, haven't used the forums in a while. Most times I stumble across a community forum post via google it is unresolved with no answer at all... On the other hand here is (mostly) always someone to help or give a hint in the right direction.
CDid you publish the worker via wrangler to start with/try wrangler now?
The Jurisdiction docs only mention it being possible to bind to a eu bucket via wrangler and the jurisdiction param
https://developers.cloudflare.com/r2/reference/data-location/#using-jurisdictions-from-workers
The Jurisdiction docs only mention it being possible to bind to a eu bucket via wrangler and the jurisdiction param
https://developers.cloudflare.com/r2/reference/data-location/#using-jurisdictions-from-workers
Learn how the location of data stored in R2 is determined and about the different available inputs that control the physical location where objects in …
KIt is deployed via wrangler and has the jurisdiction param. It has worked fine since october
Cah ok makes sense then, I don't think it ever displayed right in the UI then/let you pick it from there.
If you wrangler tail, what's the exact error its throwing? It might be helpful to just try redeploying it as well
If you wrangler tail, what's the exact error its throwing? It might be helpful to just try redeploying it as well
KCan I trigger a schedule event via wrangler? Otherwise I have to wait for the next scheduled run to happen
CIn Dev you can, not in prod. In prod your best bet is to make a secret endpoint which calls the scheduled event
KRe-deploying seems to have fixed it. But: Something must have happened on 2023-12-24 that caused the binding to stop working. Maybe someone from CF might be interested in it.
Cyea that's weird. I don't see anything on Workers or R2 change log around that date.
Do you have any deployments for that worker (under the deployments tab) on that date? Or was the last time you modified it before that?
Do you have any deployments for that worker (under the deployments tab) on that date? Or was the last time you modified it before that?
KNo, nothing. Last deployment before the issue started was on 2023-11-17. Even had a look at my audit log to see if something happened at all, nothing.
KOh, I see that on 2023-12-23 various certificates related to the worker were renewed. Both
*.{worker-name}.{subdomain}.workers.dev*.{zone-domain}.tld
DWe use Cloudflare Access to protect Workers that only have a few users (usually 1-2).
UYou can talk with sales about your use case and see if its something they can increase limits on.
DWhy do all my Workers show as
Last modified 7 days agowhen I actually click them, I see the last deployment was months ago
CDid you perhaps migrate to Standard recently?
CI think that caused that.. if i remember right?
Dyes, but I thought it was more than a week ago
Ddoes that show up in the audit logs?
CI have no idea sorry, didn't check at the time and way too long ago now
Dhmm you're probably right
DIs there a notification like this, but for Workers?
DCan you have multiple Tail Workers attached to a single Worker?
CWith smart placement, I have a worker with it enabled that proxies fetch requests from a Page function that is bound to it.
The proxy then calls our azure endpoints which are in EU. We do cname our host name e.g. api.example.com to azure via CF. I have made a few hundred requests however placement is still local. Is there no way to manually assign location?
The proxy then calls our azure endpoints which are in EU. We do cname our host name e.g. api.example.com to azure via CF. I have made a few hundred requests however placement is still local. Is there no way to manually assign location?
RHow can solve this issue
MIs there a way to use the Wrangler GH Action to publish different branches to different environments of the same worker? Or is it easier to just set up a stage worker and a live worker?
KYou can pass an environment but it has to already exist in Wrangler.toml
MAha so you mean as long as I have stage and live set up as envs in the TOML, I can then configure the Action to push one branch to one env and another branch to the other?
KYep
MThanks. Is there an example anywhere of the GH Workflow file showing this multi-branch/env approach? I'm unsure how to adapt the example file to do this.
MDo I just repeat the branches reference? i.e.
MAnd how do I associate the names of the branches with the names of my Worker envs - or must they match?
KMThanks. So the full file would be as follows? Could you possibly elaborate on what precisely that
with/environmentAppreciate the help. (Also, why do I need to get involved in specifying Linux versions? Is that just for GH not CF?)
