e.g. POST /foo -> worker kicks off an internal fetch() to /someapi, meanwhile responds to the POST /

A

AviOP•10/30/24, 6:35 PM

in my testing the subrequest is getting killed when the 202 response is sent

AAvi e.g. POST /foo -> worker kicks off an internal fetch() to /someapi, meanwhile re...

C

Chaika•10/30/24, 6:40 PM

ctx.waitUntil

C

Chaika•10/30/24, 6:40 PM

https://developers.cloudflare.com/workers/runtime-apis/context/#waituntil

Cloudflare Docs

Context (ctx) | Cloudflare Workers docs

The Context API in Cloudflare Workers, including waitUntil and passThroughOnException.

C

Chaika•10/30/24, 6:41 PM

you only get 30s of real time though for it to finish, or it'll get cancelled anyway

A

AviOP•10/30/24, 7:42 PM

got it!

A

AviOP•10/30/24, 7:42 PM

that works like a charm, thanks very much

A

Aster•10/30/24, 9:50 PM

Hey

I am trying to call a DO from Worker B when DO is exported from worker A.
Worker A looks like this:

# wrangler.toml B
name = "worker-B"
# ...
[env.dev.durable_objects]
bindings = [
  { name = "DO", class_name = "Do", script_name="worker-A" }
]

# wrangler.toml B
name = "worker-B"
# ...
[env.dev.durable_objects]
bindings = [
  { name = "DO", class_name = "Do", script_name="worker-A" }
]

# wrangler.toml B
name = "worker-B"
# ...
[env.dev.durable_objects]
bindings = [
  { name = "DO", class_name = "Do", script_name="worker-A" }
]

# wrangler.toml B
name = "worker-B"
# ...
[env.dev.durable_objects]
bindings = [
  { name = "DO", class_name = "Do", script_name="worker-A" }
]

# wrangler.toml A
name = "worker-A"
# ...
[env.dev.durable_objects]
bindings = [
  { name = "DO", class_name = "Do" }
]

[[migrations]]
tag = "v1"
new_sqlite_classes = ["Do"]

# wrangler.toml A
name = "worker-A"
# ...
[env.dev.durable_objects]
bindings = [
  { name = "DO", class_name = "Do" }
]

[[migrations]]
tag = "v1"
new_sqlite_classes = ["Do"]

# wrangler.toml A
name = "worker-A"
# ...
[env.dev.durable_objects]
bindings = [
  { name = "DO", class_name = "Do" }
]

[[migrations]]
tag = "v1"
new_sqlite_classes = ["Do"]

# wrangler.toml A
name = "worker-A"
# ...
[env.dev.durable_objects]
bindings = [
  { name = "DO", class_name = "Do" }
]

[[migrations]]
tag = "v1"
new_sqlite_classes = ["Do"]

And the index.ts in worker B is a fetch calling a DO stub (with RPC), and exporting the fetch.
On Worker A, it's a simple fetch + DO sqlite, both exported.

Worker A deploys fine and works fine with DO. I get this error on deploy for worker B (that should use the DO from worker A):

Cannot create binding for class in script 'worker-A' that does not exist [code: 10061]

Cannot create binding for class in script 'worker-A' that does not exist [code: 10061]

Cannot create binding for class in script 'worker-A' that does not exist [code: 10061]

Cannot create binding for class in script 'worker-A' that does not exist [code: 10061]

Any idea what I could be doing wrong?

A

Aster•10/30/24, 10:07 PM

Found it! the script name needs to be worker-A-dev

DDean as far as i can see - despite the API endpoint, it's impossible to use /settings...

D

Dean•10/30/24, 10:59 PM

guessing i'm out of luck? can't really use D1 if you can't bind anything on the fly.

DDean guessing i'm out of luck? can't really use D1 if you can't bind anything on the ...

H

Hello, I’m Allie!•10/30/24, 11:13 PM

Have you tried using SQLite DOs instead of D1?

HHello, I’m Allie!Have you tried using SQLite DOs instead of D1?

D

Dean•10/30/24, 11:22 PM

1G storage is prohibitive for us. I'm just not sure why the API just returns success = true but nothing happens

DDean guessing i'm out of luck? can't really use D1 if you can't bind anything on the ...

K

kian•10/30/24, 11:28 PM

How "on the fly" are you looking for? It wouldn't affect that Worker invocation that calls it.

Kkian How "on the fly" are you looking for? It wouldn't affect that Worker invocation ...

D

Dean•10/30/24, 11:40 PM

my plan is when someone clicks something from my CF pages site, it creates a D1 database and we need to bind that to 3 CF workers. It doesn't have to be instant but quick enough that it's not waiting 5 - 10 minutes

K

kian•10/30/24, 11:51 PM

How are you using the API? Wrangler itself uses it so it should be fine

Kkian How are you using the API? Wrangler itself uses it so it should be fine

D

Dean•10/31/24, 12:02 AM

cant use wrangler because its done by the client in pages

D

Dean•10/31/24, 12:05 AM

i'm using this endpoint: https://developers.cloudflare.com/api/operations/worker-script-patch-settings but it just reutrns sucess = true and bindings are never updated

Cloudflare API Documentation

Interact with Cloudflare's products and services via the Cloudflare API

D

Dean•10/31/24, 12:05 AM

even though it does generate a new deployment

D

Dean•10/31/24, 12:05 AM

afaik - as long as it's formatted right, it'll always respond success no matter the input

K

kian•10/31/24, 12:06 AM

What's your payload?

D

Dean•10/31/24, 12:11 AM

Sending body: ---------------formdata45241039827298346
Content-Disposition: form-data; name="settings"

{"settings":{"bindings":[{"database_id":"821eb65a-ebdd-49ef-aa0b-878f65b57d57","name":"inbound-5772b3b2-6bca-42ed-938b-f3e17b2781ca","type":"d1","id":"821eb65a-ebdd-49ef-aa0b-878f65b57d57"}]}}
---------------formdata45241039827298346--
Worker binding response: {
"result": {
"placement": {},
"compatibility_date": "2024-09-08",
"compatibility_flags": [],
"usage_model": "standard",
"tags": [],
"tail_consumers": [],
"logpush": false,
"bindings": [
{
"database_id": "2206f7ed-1476-40a0-9758-f1bc3d47e5ad",
"id": "2206f7ed-1476-40a0-9758-f1bc3d47e5ad",
"name": "2206f7ed-1476-40a0-9758-f1bc3d47e5ad",
"type": "d1"
},

]
},
"success": true,
"errors": [],
"messages": []
}
Worker binding process completed

D

Dean•10/31/24, 12:11 AM

had to purge some of the bindings that have came back because length

D

Dean•10/31/24, 12:12 AM

ive done a ton of different configurations, incl passing existing bindings through, matching all the flags in the result, etc with no real change

K

kian•10/31/24, 12:14 AM

Remove the top-level settings object

D

Dean•10/31/24, 12:14 AM

it's required, if you don't pass that it says missing settings

K

kian•10/31/24, 12:15 AM

I mean lift bindings to the top-level

K

kian•10/31/24, 12:15 AM

i.e

data.set("settings", JSON.stringify({ bindings }));

data.set("settings", JSON.stringify({ bindings }));

data.set("settings", JSON.stringify({ bindings }));

data.set("settings", JSON.stringify({ bindings }));

K

kian•10/31/24, 12:15 AM

where

data

data

is a FormData object

D

Dean•10/31/24, 12:18 AM

hmm that actually worked

D

Dean•10/31/24, 12:18 AM

appreciate the assist on that, ty!

K

kian•10/31/24, 12:21 AM

You will want to do the "incl passing existing bindings through" part though too!

P

parisholley•10/31/24, 1:08 AM

is there an outage? can't deploy ("Observability was requested but not allowed") or access dashboard: "The Cloudflare dashboard is loading."

P

parisholley•10/31/24, 1:09 AM

nevermind, status page just updated

Pparisholley nevermind, status page just updated 🙂

I

Isaac McFadyen•10/31/24, 1:10 AM

Yup

I

Isaac McFadyen•10/31/24, 1:10 AM

They're working on it internally

Kkian You will want to do the "incl passing existing bindings through" part though too...

D

Dean•10/31/24, 1:55 AM

Yep, it overwrote my bindings but that’s ok

I have the code to implement them already. Really appreciate the help on that one, was driving me crazy

S

Sxyzo•10/31/24, 2:33 AM

Hi! I'm trying to get two Workers to communicate using RPC, but it's not working when I try to use a named export.

When I try to call

methodX()

methodX()

methodX()

methodX(), I get this error:

The RPC receiver does not implement the method "methodX"

The RPC receiver does not implement the method "methodX"

The RPC receiver does not implement the method "methodX"

The RPC receiver does not implement the method "methodX"

Here's my setup that's NOT working:

In Worker A's config file (wrangler.toml), I have:

compatibility_date = "2024-10-22"
[[env.staging.services]]
binding = "STORAGE_SERVICE"
service = "storage_service"
entrypoint = "StorageService"

compatibility_date = "2024-10-22"
[[env.staging.services]]
binding = "STORAGE_SERVICE"
service = "storage_service"
entrypoint = "StorageService"

compatibility_date = "2024-10-22"
[[env.staging.services]]
binding = "STORAGE_SERVICE"
service = "storage_service"
entrypoint = "StorageService"

compatibility_date = "2024-10-22"
[[env.staging.services]]
binding = "STORAGE_SERVICE"
service = "storage_service"
entrypoint = "StorageService"

And in Worker B, I'm doing:

export class StorageService extends WorkerEntrypoint<Bindings> {
    async methodX() {
        // stuff happens here
    }
}
export default {
    async fetch() {
        return new Response("Hello world");
    }
}

export class StorageService extends WorkerEntrypoint<Bindings> {
    async methodX() {
        // stuff happens here
    }
}
export default {
    async fetch() {
        return new Response("Hello world");
    }
}

export class StorageService extends WorkerEntrypoint<Bindings> {
    async methodX() {
        // stuff happens here
    }
}
export default {
    async fetch() {
        return new Response("Hello world");
    }
}

export class StorageService extends WorkerEntrypoint<Bindings> {
    async methodX() {
        // stuff happens here
    }
}
export default {
    async fetch() {
        return new Response("Hello world");
    }
}

But here's the weird part

if I remove the named entrypoint stuff and just do it like this, it works perfectly:

compatibility_date = "2024-10-22"
[[env.staging.services]]
binding = "STORAGE_SERVICE"
service = "storage_service"

compatibility_date = "2024-10-22"
[[env.staging.services]]
binding = "STORAGE_SERVICE"
service = "storage_service"

compatibility_date = "2024-10-22"
[[env.staging.services]]
binding = "STORAGE_SERVICE"
service = "storage_service"

compatibility_date = "2024-10-22"
[[env.staging.services]]
binding = "STORAGE_SERVICE"
service = "storage_service"

ith Worker B simplified to:

export default class StorageService extends WorkerEntrypoint<Bindings> {
    async methodX() {
        // stuff happens here
    }
}

export default class StorageService extends WorkerEntrypoint<Bindings> {
    async methodX() {
        // stuff happens here
    }
}

export default class StorageService extends WorkerEntrypoint<Bindings> {
    async methodX() {
        // stuff happens here
    }
}

export default class StorageService extends WorkerEntrypoint<Bindings> {
    async methodX() {
        // stuff happens here
    }
}

Any ideas what I might be doing wrong with the named export version? I kind of need to keep that structure for other parts of my app.

Thanks in advance!

K

kian•10/31/24, 2:40 AM

https://developers.cloudflare.com/workers/wrangler/configuration/#service-bindings

K

kian•10/31/24, 2:41 AM

You need to specify the named entrypoint in your Wrangler.toml.

K

kian•10/31/24, 2:41 AM

The name of the entrypoint to bind to. If you do not specify an entrypoint, the default export of the Worker will be used.

S

Sorren•10/31/24, 5:46 AM

im so confused. where do i run all the $ commands i keep seeing in tutorials, im on windows

SSorren im so confused. where do i run all the $ commands i keep seeing in tutorials, im...

Z

Zaid•10/31/24, 6:27 AM

Those are probably shell commands. On macOS/Linux you run them in a Terminal, on Windows the easiest way is probably to use WSL https://learn.microsoft.com/en-us/windows/wsl/

Windows Subsystem for Linux Documentation

Overview of the Windows Subsystem for Linux documentation.

Kkian You need to specify the named entrypoint in your Wrangler.toml.

S

Sxyzo•10/31/24, 11:00 AM

Thanks for your reply, but the issue is that it has already been specified and it doesn't work

compatibility_date = "2024-10-22"
[[env.staging.services]]
binding = "STORAGE_SERVICE"
service = "storage_service"
entrypoint = "StorageService"

compatibility_date = "2024-10-22"
[[env.staging.services]]
binding = "STORAGE_SERVICE"
service = "storage_service"
entrypoint = "StorageService"

compatibility_date = "2024-10-22"
[[env.staging.services]]
binding = "STORAGE_SERVICE"
service = "storage_service"
entrypoint = "StorageService"

compatibility_date = "2024-10-22"
[[env.staging.services]]
binding = "STORAGE_SERVICE"
service = "storage_service"
entrypoint = "StorageService"

S

Sxyzo•10/31/24, 11:01 AM

I'm not sure what I'm doing wrong.

�

😈 Donkey 💫•10/31/24, 11:30 AM

const response = await env.AI.run(
            ("@hf/meta-llama/meta-llama-3-8b-instruct",
            payload
        );
    return new Response(response, {
        headers: {
            "content-type": "text/event-stream",
        },
    });

const response = await env.AI.run(
            ("@hf/meta-llama/meta-llama-3-8b-instruct",
            payload
        );
    return new Response(response, {
        headers: {
            "content-type": "text/event-stream",
        },
    });

const response = await env.AI.run(
            ("@hf/meta-llama/meta-llama-3-8b-instruct",
            payload
        );
    return new Response(response, {
        headers: {
            "content-type": "text/event-stream",
        },
    });

const response = await env.AI.run(
            ("@hf/meta-llama/meta-llama-3-8b-instruct",
            payload
        );
    return new Response(response, {
        headers: {
            "content-type": "text/event-stream",
        },
    });

hello,

I want to append a new custom event, like event.type = 'app_event', then my worker can send additional data to client

How to do that?

PPuliczek Any one tried workers with hono+remix? I know that now we can run remix with wor...

B

Bonadio•10/31/24, 3:27 PM

This is on pages but it is working, I am trying to figure out if I should go for Pages or Workers for a new Remix project.

https://github.com/yusukebe/hono-and-remix-on-vite/tree/main

GitHub

GitHub - yusukebe/hono-and-remix-on-vite

Contribute to yusukebe/hono-and-remix-on-vite development by creating an account on GitHub.

B

Bonadio•10/31/24, 3:33 PM

Hello, I have a new project to start using Remix, should I go for Remix on PAGES or WORKERS?

BBonadio Hello, I have a new project to start using Remix, should I go for Remix on PAGES...

T

texan•10/31/24, 3:37 PM

Check out the compatibility matrix here: https://developers.cloudflare.com/workers/static-assets/compatibility-matrix/

Cloudflare Docs

Workers vs. Pages (compatibility matrix) | Cloudflare Workers docs

Compatibility matrix for asset hosting on Cloudflare Workers and Pages.

C

Chaika•10/31/24, 3:38 PM

also it really depends if your framework supports Pages or Workers. For remix, it looks like both: https://developers.cloudflare.com/workers/frameworks/framework-guides/remix/
Workers Assets are only in beta too, as well

Cloudflare Docs

Remix | Cloudflare Workers docs

Create a Remix application and deploy it to Cloudflare Workers with Workers Assets.

Ttexan Check out the compatibility matrix here: https://developers.cloudflare.com/worke...

B

Bonadio•10/31/24, 3:39 PM

Hi Will, in this page there is this "We plan to bridge the gaps between Workers and Pages and provide ways to migrate your Pages projects to Workers."

So I understand that the future will be workers in place of pages. Is my understand correct?

e.g. POST /foo -> worker kicks off an internal fetch() to /someapi, meanwhile responds to the POST /

Similar Threads

Similar Threads

Similar Threads