I can't do that, each account is for a different job
I can't do that, each account is for a different job
HYou could provide an API token as an env var?
CLOUDFLARE_API_TOKEN I believe
Pan add that to the variables in the wrangler.toml?
HNo, I meant an Env Var in the console
HLike
Pohh okay, and instead of login in i just use the api token each time/
Pthats clever haha
Pthanks!
MWith the worker pricing model change I have a question about Service Bindings that I cannot fully confirm based on old similar questions and the current docs.
If I have a Cloudflare Pages project that does SSR on a page (then triggering a worker request through it's adapter) and I need to request an endpoint on a Hono API that is deployed on another Worker (on a different subdomain) and I wire them as Service Bindings, do I still trigger 2 requests each time a user refreshes the page or the counter get's only the Pages request against my limit?
If I have a Cloudflare Pages project that does SSR on a page (then triggering a worker request through it's adapter) and I need to request an endpoint on a Hono API that is deployed on another Worker (on a different subdomain) and I wire them as Service Bindings, do I still trigger 2 requests each time a user refreshes the page or the counter get's only the Pages request against my limit?
HAt the moment, a call to a Service Binding is billed as a new request
MFrom current docs I understand that the request to the Hono API will just count against the subrequests of the Pages Worker
https://developers.cloudflare.com/workers/runtime-apis/bindings/service-bindings/#limits
So to avoid a double request I'm supposed to move all the backend logic from my main API to the Pages SSR request? That's unfortunate
https://developers.cloudflare.com/workers/runtime-apis/bindings/service-bindings/#limits
So to avoid a double request I'm supposed to move all the backend logic from my main API to the Pages SSR request? That's unfortunate
Cloudflare Docs
Facilitate Worker-to-Worker communication.
HAt the moment anyway. There was a discussion about making service binding calls free, but haven't seen anything new on that front yet
USubrequests are just any network call, you arent billed on subrequests. Service bindings specifically call another worker and all worker requests are billed regardless of request method which is why calling service bindings has a charge.
HThough note, because of the architecture of Service Bindings, the bound Worker should already be in memory, and thus calling it is almost like calling a function within your Worker directly(which I suspect is why they might want to make Service Binding calls free).
MThanks for the quick reply, hope to also have at least 2 chained requests for free in the future, anyway not sure again about the content of this article https://blog.cloudflare.com/service-bindings-ga being still valid, I understand that many changes have happened since it has been written, but having an
api-gateway like architecture with workers (aka triggering 4+ requests only to have a login token returned) it's too expensive in the long run, only the security from the subworkers isolation might be a perk.The Cloudflare Blog
Service bindings are an API that facilitate Worker-to-Worker communication. You can invoke other Workers directly from your code; making it possible to communicate with shared services. We’ll also make it cost-efficient to run multiple Workers.
UIt might be "expensive" for personal use but for companies even 4 requests is still only $1.20/million (+ some cpu time). My work does about $15-20/million requests comparitively on AWS so theres that 
K@sperand_io @elithrar @Cloudflare Two things here:
- We are working on (couldn't quite make it for this week) a change where when you call another Worker via a service binding, this won't be billed as a request. (so that pricing doesn't disincentivize breaking apart an app into many Workers) Coming soon.
4/5/24, 7:31 PM
KHello everyone, Is it possible to send emails with attachments using the mailchannels plugin? Or has this feature not been implemented?
AIs anyone successfully seeing unobfuscated stack traces in the exception output of the real time logs?
Ai've got
upload_source_maps = true and i'm still not seeing themAi'm also watching for exceptions. i'm not merely looking at a console.log of the
error.stackAThis page says stack traces go into open beta on apr 15th. that's in the past, but also pretty recent. so maybe they're just not rolled out yet? https://developers.cloudflare.com/workers/observability/source-maps/
A
Ldo tail workers generate a new tail worker if they crash to handle their own events or does the chain stop at tail workers?
MAnyone from CF able to help here?
DI know I’ve asked this before.. is there a way to use something like HTTP 100 in a Worker to avoid a 524 timeout?
DYep I already did that. I just am looking for a more generic solution.
We’re probably migrating off enterprise next month too.
We’re probably migrating off enterprise next month too.
D@Leo oh wait, is the 100 second timeout only on subrequests and not requests to the Worker itself?
DWe’ll be on pro next month so same. 
DIf I return even just 1 bytes, that will “reset” my 100 second timeout, right?
CIs there any way to protect the contents of both the Worker and the KV data on a client site? There's some proprietary data we want fast access to, so were using KV to store, but ideally it would be something that isn't public (even though it's the Client's Cloudflare account)
DMy idea is to try returning whitespaces until the response is ready.
HNot really. Anything on their Cloudflare account is theirs to see. You could call out to an external API to get the data, but the data will still be in their hands at some point
CIf the external API was also Cloudflare, would it mean it could be very fast? The benefit of it being within the client account is performance and it’s straightforward, there’s some data we would like to add that it’s better if it’s not all public so may look at how to do this or obfuscate it a bit
HSure, it should be pretty fast. Just keep in mind that any data that reaches the Client's Worker is theoretically something they have access to
NI have a question regarding protection against denial of wallet for public worker/function endpoints. In case an attacker found some way to get thousand of ip addresses and used them to send billions of requests to the public endpoint (which is quite common these days), what are some possible approaches/implementations that could turn off your worker automatically if a monthly threshold is exceeded (the threshold could be either the global number of requests or a specific bill amount)?
I believe that in such a scenario for an organisatiton with limited funds, the only thing that you can do is turn off the worker and the availability of its online service (since the bill amount has exceeded you budget or bank account balance). Please correct me if there's other strategies to handle this.
I believe that in such a scenario for an organisatiton with limited funds, the only thing that you can do is turn off the worker and the availability of its online service (since the bill amount has exceeded you budget or bank account balance). Please correct me if there's other strategies to handle this.
CUnderstood, I know it’s something they would be able to see but for the use case it’s slightly better if they don’t have all of the data together, both to protect it but also for updates so we would control data in one place rather than multiple KVs, I’ll look into it!
NOh that would be nice, is there any official documentation for that?
NIt is, but that doesn't mean I wouldn't have to pay the bill if the attacker succeded the ddos...
BActually they take off any legitimate ddoses from your bill 
NThis would be awesome from Cloudflare, but is there any official reference for this that I can share with my collaborators?
BThere's only this message from someone with a role in the server here, it's more of a support policy they have than an official "feature" that would be documented.
https://discord.com/channels/595317990191398933/909458221419356210/1041778929654055026
https://discord.com/channels/595317990191398933/909458221419356210/1041778929654055026
BAll account analytics are accessible over GraphQL if you wanted to build your own kill-switch too: https://developers.cloudflare.com/analytics/graphql-api/
Cloudflare Docs
The GraphQL Analytics API provides data regarding HTTP requests passing through Cloudflare’s network, as well as data from specific products, such as …
BThis is on their site too under the DDoS Page
NThanks a lot for the information 
MIs workers for plattforms already available as a pay-as-you-go option? Docs are still talking about that happening "on April 16th". :|
CC#workers-for-platforms
C
Momg totally missed that, thx!
