Can a bundled worker know it's CPU usage? I have a task that consists of a long series of API calls

Can a bundled worker know it's CPU usage? I have a task that consists of a long series of API calls and wanted to know when it would be time to kick-off the next bundled service worker.

Bbret_pat Can a bundled worker know it's CPU usage? I have a task that consists of a long ...

Hello, I’m Allie!•4/13/23, 9:55 PM

It cannot

SSanju Hi everyone, how to use workers cron to trigger certain endpoint?. For example -...

chientrm.com•4/14/23, 4:42 AM

use

fetch

fetch

SSanju Can you elaborate more on this? @chientrm

chientrm.com•4/14/23, 4:45 AM

https://developers.cloudflare.com/workers/platform/triggers/cron-triggers/

chientrm.com•4/14/23, 4:45 AM

https://developers.cloudflare.com/workers/runtime-apis/fetch/

bret_patOP•4/14/23, 5:59 AM

How can I trigger a cloudflare worker from a non-cloudflare backend? Can I enqueue a message from a non cloudflare worker as well?

Bbret_pat How can I trigger a cloudflare worker from a non-cloudflare backend? Can I enqu...

Hello, I’m Allie!•4/14/23, 6:01 AM

Just send an HTTP request?

HHello, I’m Allie!Just send an HTTP request?

bret_patOP•4/14/23, 6:03 AM

In that scenario, I would be responsible for creating my own means of authenticating the request.

bret_patOP•4/14/23, 6:04 AM

But gotcha. I guess I was just wondering if there was a client library of some sort or not

Bbret_pat But gotcha. I guess I was just wondering if there was a client library of some s...

Hello, I’m Allie!•4/14/23, 6:05 AM

Not really, because any HTTP(S) request hitting a route covered by a Worker will run said Worker

Hello, I’m Allie!•4/14/23, 6:06 AM

There isn’t really anything there for the library to do

Hello, I’m Allie!•4/14/23, 6:06 AM

At least not with just a regular Worker

Hello, I’m Allie!•4/14/23, 6:07 AM

If you are running a GraphQL server on Workers, then there are a few libs to choose from there

airplantlifestyle•4/14/23, 6:17 AM

Hey folks, here's something that kept me up all night: I'm making a request to a db running on my server from within a worker. Running it locally works fine, but fails once it's deployed. I've been looking at the access logs on the server and the requests coming from the deployed worker seem off:
(worker on CF): "GET /api/health HTTP/1.1" 404 19 "-" "-" 331 "-" "-" 0ms"GET /api/health HTTP/1.1" 404 19 "-" "-" 331 "-" "-" 0ms
(worker running locally): "GET /api/health HTTP/1.1" 200 41 "-" "-" 355 "pb1@docker" "http://172.24.0.5:8090" 1ms"GET /api/health HTTP/1.1" 200 41 "-" "-" 355 "pb1@docker" "http://172.24.0.5:8090" 1ms

I notice that all the requests initiated from the deployed worker (even those with a body etc) all have only 19 bytes19 bytes request size. It's a long shot, but what are your thoughts on that?

kian•4/14/23, 6:20 AM

Are you fetching an IP and/or on a non-standard port?

kian•4/14/23, 6:20 AM

If not, would need to see what the

fetch

fetch

code looks like

airplantlifestyle•4/14/23, 6:25 AM

Just your vanilla fetch:

const x = await fetch("https://db-dev.textmait.se/api/health");
console.log("Health", x.status);

const x = await fetch("https://db-dev.textmait.se/api/health");
console.log("Health", x.status);

airplantlifestyle•4/14/23, 6:25 AM

I already had the thought that it could have something to do with maybe certificates, but I guess then the request would fail in a different way?

airplantlifestyle•4/14/23, 6:28 AM

The thing that throws me off is that my reverse proxy (traefik) is the one returning the 404, it doesn't seem to be able to route it to the right docker container. So it's either an issue with the rev. proxy (traefik), or it's an issue with the request itself (cloudflare)

airplantlifestyle•4/14/23, 6:36 AM

Okay, just deployed a minimal example, and here the requests are fine (result and server logs). Must be something with the deployment config of the other worker.

airplantlifestyle•4/14/23, 6:40 AM

Update: It's a Cloudflare issue with custom domains. As soon as I add route = { pattern = "api2.textmait.se", custom_domain = true, zone_id = "xxx" }route = { pattern = "api2.textmait.se", custom_domain = true, zone_id = "xxx" } to my wrangler config, the requests fail. Any pointers to how my config is wrong?

kian•4/14/23, 6:42 AM

Is the Worker you're fetching from also on textmait.se?textmait.se?

kian•4/14/23, 6:42 AM

Same-zone subrequests are, uh, annoying

airplantlifestyle•4/14/23, 6:43 AM

Yup, db-dev.textmait.sedb-dev.textmait.se is an A record pointing to my server, api2.textmait.seapi2.textmait.se is managed by CF to point to the worker.

kian•4/14/23, 6:43 AM

Add

# https://github.com/cloudflare/workers-sdk/issues/2659
compatibility_flags = ["no_minimal_subrequests"]

# https://github.com/cloudflare/workers-sdk/issues/2659
compatibility_flags = ["no_minimal_subrequests"]

to your wrangler.toml

kian•4/14/23, 6:44 AM

you can track that issue to know when you can remove the compatibility flag

airplantlifestyle•4/14/23, 6:47 AM

Thank you! What exactly does this do? Because I'm not seeing any changes after deploying with it

kian•4/14/23, 6:47 AM

No idea - it's just what the Workers team recommend in that linked issue which supposedly fixes the same-zone subrequests

airplantlifestyle•4/14/23, 6:50 AM

Huh, okay. Tbh, never heard about same-zone subrequests until now, so I'll keep that in mind. I've at least now have our service back and running by using the .workers.dev domain, so thank you very much for pointing me into the right direction!

kian•4/14/23, 6:50 AM

Historically, a Worker on foo.comfoo.com has never been able to fetch anything else on foo.comfoo.com

kian•4/14/23, 6:50 AM

Using a custom domain (rather than a route) allowed it to fetch other things on foo.comfoo.com

kian•4/14/23, 6:50 AM

but then minimal_subrequestsminimal_subrequests (default as of 2022-04-052022-04-05) broke that

airplantlifestyle•4/14/23, 6:51 AM

Wow that's fascinating. I think I wouldn't have been able to figure that out by myself

airplantlifestyle•4/14/23, 6:51 AM

Worst case I gotta buy a second domain for the api

kian•4/14/23, 6:51 AM

It really should just work - comment on https://github.com/cloudflare/workers-sdk/issues/2659 that it's still broken for you and the team might have other suggestions

kian•4/14/23, 6:52 AM

That issue is more for Worker <-> Worker so there might be another bug for your Worker <-> Proxied Origin scenario

airplantlifestyle•4/14/23, 6:54 AM

Thank you, I'll do that!

plutoniumm•4/14/23, 5:45 PM

hey so idk if this is the right place for it please redirect me to the appropriate person if needed. I noticed the WASM Runtime is public under the workerdworkerd package on NPM. I happen to hold the workeredworkered (with the 'e') package name but its not doing much and I don't need it. So I can release it if Cloudflare can put that to better use?

plutoniumm•4/14/23, 5:46 PM

Asking so that if you need it and I do it on the wrong time someone else would probably take it up lol

kian•4/14/23, 5:51 PM

Cloudflare doesn’t hold a trademark for workerd but I can see how that package name could be used maliciously for typos - cc @veerooo who can get the message to the right people

James•4/14/23, 6:34 PM

Functionally that code will work, but you won't really get the benefit of cache when you're combining scheduled workers + real traffic. cachecache is datacenter specific, and scheduled workers run in a subset of datacenters, so if you get traffic in a datacenter that your schedule didn't run in, it won't have a cache. And if that only runs once per hour for example, it's only cached in 1 location.

Your better option here would probably be to store the info to KV on that schedule instead - that provides much more of a guarantee, and will be quick to retrieve.

Can a bundled worker know it's CPU usage? I have a task that consists of a long series of API calls

Similar Threads

Similar Threads

Similar Threads