If you want to cut it short, pass an

AbortSignal.timeout

to the

signal

property in the

fetch

options

nice! that does work!

cool, i feel like i finally understand this a bit more

i guess the "freezing" behavior (as implemented in that PR you linked) is just a bit overzealous in

--local

vs dev/new local

thanks for your help

also, slightly OT, but do you know when DOs spin down/ or whatever the correct terminology is for a cloudflare worker that is a DO "going way"? like if i do this

setInterval

in the DO, such that it's always doing periodic CPU work... will that cause it to never sleep? or will it sleep iff nobody is connected to it?

When it stops serving requests, it'll go inactive for 30 seconds where it's alive but you're not being charged for duration - after that, it'll be 'evicted' and go bye-bye until it's next requested

Your

setInterval

might keep it alive though - says 'all asynchronous I/O'

If you ask in #773219443911819284 the team behind them can probably give you a concrete answer

got it! thank you

Is this a hard limit or something I can request an increase for?

This script has too much traffic: 247 invocations per second, which is over the limit of 200.

That's a current technical limit of live tailing logs you should use logpush to send logs to something like S3/R2/etc

We're also seeing invocations to this worker fail at the same time. Is that a red herring or could they be related?

That wouldn't be related or I doubt it would be

Thank you! I'll dig further then!

I feel like I might be missing something. I'm trying to create a private admin panel for some basic things, the admin panel will be private and access a private API. I was thinking I could fairly easily put the Cloudflare Pages admin panel behind Zero Trust, then validate with that somehow on the API side. Am I wrong in this?

or should I just make my own login system with usernames/passwords etc

How do you guys organize project folder structures with multiple workers?

I try to not use multiple workers instead

It totally works.

@sirhype How does the admin panel call the private API? From the frontend or the backend? Cloudflare Access is a tad easier to work with on SSR webapps because it will protect all route with authentication and redirect to a Web portal. If you're protecting an SPA qith Cloudflare Access, you have a tad more work to do.

hey quick question -- using service bindings with cloudflare workers i bound one on my connecting worker how do i know if its working as far when i make the connection over a custom domain i see both workers see each other connections but i "should" expect subrequests fall under the 1k limit not 50 since its internal when using fetch would that be accurate? my fetch code

const init = {
          status:200,
          method: 'GET',
          headers: {
            "content-type": "application/json",
            "User-Agent": USER_AGENT_HEADER,
            "Accept": "application/json",
            "Access-Control-Allow-Origin": "*"
          },
        }

        url = "https://customworkerdomain.com" //(this is bound to the source worker)
        const request = new Request(url, init)
        const response = await fetch(request)

i feel like i am missing a step as i feel like the subrequests of 50 are still applying -- anyway to tell easily 😄 as i see the worker getting requests 😄

btw @kian after lots of hair pulling -> got my first wrangler going last week with the SSL3/crypto library hashing :D. thx for the help too last week

> how do i know if its working as far when i make the connection over a custom domain I don't understand this part.

If what you want to call a worker from another worker, then you need to get the service binding from the

env

object.

This part > const response = await fetch(request) becomes > const response = env[nameOfTheBinding](request)

The URL is irrelevant, at least as far as Cloudflare is concerned. You can put anything that fetch will accept. It's up to you.

I have a few questions about service bindings. I just read this from the docs (https://developers.cloudflare.com/workers/runtime-apis/service-bindings#shared-resources): > Workers connected to one another via Service bindings share the CPU resources of the top-level request. A single thread is allocated and reused amongst these Workers. This means no idle resources are wasted while work is performed across various Workers. I wonder about the implications: - Does the CPU-time limit apply across the pipeline or worker by worker? - If a Bundled worker calls an Unbound worker through service bindings, what happens?

Can I get some help merging these two functions into one please?

if (STUFF) 
    {
      response.headers.set(
        "Set-Cookie",
        "pricing-mode=on;max-age=604800;Path=/"
      )
      if (!contentType.startsWith("text/html")) {
        return response;
      }
      html.on("body", new PRICING_MODE_ON());
    }

Trying to set cookie and return html body response in one IF