You can't invoke the same 'instance' of a Worker. They're inherently stateless, so a second invocation of a Worker creates a new 'instance' of it. (I put instance in quotes because they're not actually instances, but the concept is relatable) Client A calls Worker A and Worker A calls Worker B. If they're both on Unbound, that's 2 invocations and one 'flattened' duration for the time spent across both Worker A & B. Client B calls Worker A and Worker A calls Worker B. Now you're at 4 invocations and 2 'flattened' durations for the time spent across both Worker A & B in each top level request.

Gotcha. (apologies if this question is stupid) global variables are common across instances running in the same isolate, though, right?

I wouldn't count on using globals to store state across Workers. We often do GC and you have no real predictable way of knowing that subsequent requests will hit the same isolate. Instead Durable Objects are great for state (actor model), as are storage options like KV (eventually consistent) / D1 (open alpha) / etc

Makes sense to not rely on globals. But

waitUntil

should keep those vars and the Worker instance around...? Agree that DOs are better suited, even if just a little expensive than Workers Unbound. Btw, Deployments for Workers announced today is fire 🔥 not just flare 🔦 Congratulations. Can't wait for rollbacks (:

Would love to hear about your thoughts on deployments! Will DM

Is it possible to safely determine that a request to a worker, orginates from a subrequest through a service binding? I would like to modify or possibly even disable, some authentication methods when api:s is invoked through service bindings

You could add some data to req.cf?

I'm not sure if that'll go through though..

I'd personally just set a header to something

Don’t they? I feel like someone has talked about doing that before…

I honestly don't know - but it sounds like a hack at best

Same with the header, except now you have to ensure people don’t just set it manually

If you just set a long value, it'll be near impossible to guess

One thing that is guaranteed to pass through is the headers, that's much less of a hack

Thanks I will check it out 👍

Yeah I could set a header if I find no other way

they do

setting Request.cf properties is the recommended way

interesting - we are doing this - but it always seemed like a hack ... so this is the recommended way?

Yep, you can always rest assured that nothing outside of Cloudflare can set cf properties, so it's recommended for communicating things like whether a request came from another Worker.

Is the fact that it is passed on documented somewhere?

Maybe? Might not be given how many people don't realize it's expected behavior...

Also just want to make sure that it is guaranteed to exist later on, as generally, features that are documented are less likely to just disappear because of some internal decision.

Hey guys, what workers-types is for Service bindings? Just

Fetcher

?

That's right 🙂

Hello, Does anyone know if calls to service bindings count towards the quota? for example the daily 100k free request in the free plan

They will count as an invocation on the worker that calls the service binding, and another on the service binding. So if Worker A calls Worker B via service binding, you'll incur 2 invocations, for example.

So, yes

Thank you very much @James

------------------------------ *This channel is archived, please use #779390076219686943 * ------------------------------