I think you can bind it directly within that same worker and access it via `env` , here’s a demo: ht

Iixixix I think you can bind it directly within that same worker and access it via `env`...

D

DiamondDragon•10/30/24, 3:15 PM

Thanks I’ll try that out

Iixixix I think you can bind it directly within that same worker and access it via `env`...

D

DiamondDragon•10/30/24, 3:22 PM

I’m also gonna try calling a rpc in a workflow. Wondering if that will work

G

Grifed•10/30/24, 4:54 PM

Hello everyone, have any of you tried to deploy nextjs on workers?

GGrifed Hello everyone, have any of you tried to deploy nextjs on workers?

F

fry69•10/30/24, 4:57 PM

See here -> https://developers.cloudflare.com/workers/frameworks/framework-guides/nextjs/

Ffry69 See here -> https://developers.cloudflare.com/workers/frameworks/framework-guide...

G

Grifed•10/30/24, 5:08 PM

Thanks ! Which is better cloudflare pages or workers for nextjs

GGrifed Thanks ! Which is better cloudflare pages or workers for nextjs

F

fry69•10/30/24, 5:12 PM

No clue. Workers are more up-to-date and powerful though.

Iixixix I think you can bind it directly within that same worker and access it via `env`...

D

DiamondDragon•10/30/24, 5:42 PM

Working through this example... Is this bug described here still outstanding? https://github.com/cloudflare/js-rpc-and-entrypoints-demo/blob/12f7f2e10a4543c229554bcec4cba139e16594ce/public-admin-api-interfaces/db-service/wrangler.init.toml

✔ script to run › worker:dev-local
$ wrangler dev

 ⛅️ wrangler 3.84.0
-------------------

Using vars defined in .dev.vars
Your worker has access to the following bindings:
- Workflows:
  - SEARCH_WORKFLOW: SearchWorkflow
  - TEST_WORKFLOW: TestWorkflow
- Services:
  - TEST_SERVICE: 🔴 test-service#TestService
- Vars:
  - TURSO_TOKEN: "(hidden)"
  - TURSO_URL: "(hidden)"
  - WEBSHARE_PROXY_URL: "(hidden)"
  - CLOUDFLARE_ACCOUNT_ID: "(hidden)"
  - CLOUDFLARE_ACCESS_KEY_ID: "(hidden)"
  - CLOUDFLARE_SECRET_ACCESS_KEY: "(hidden)"
▲ [WARNING] This worker is bound to live services: TEST_SERVICE (test-service#TestService)


[wrangler:inf] Ready on http://localhost:8787
⎔ Starting local server...

✘ [ERROR] The Workers runtime failed to start. There is likely additional logging output above.


If you think this is a bug then please create an issue at https://github.com/cloudflare/workers-sdk/issues/new/choose

✔ script to run › worker:dev-local
$ wrangler dev

 ⛅️ wrangler 3.84.0
-------------------

Using vars defined in .dev.vars
Your worker has access to the following bindings:
- Workflows:
  - SEARCH_WORKFLOW: SearchWorkflow
  - TEST_WORKFLOW: TestWorkflow
- Services:
  - TEST_SERVICE: 🔴 test-service#TestService
- Vars:
  - TURSO_TOKEN: "(hidden)"
  - TURSO_URL: "(hidden)"
  - WEBSHARE_PROXY_URL: "(hidden)"
  - CLOUDFLARE_ACCOUNT_ID: "(hidden)"
  - CLOUDFLARE_ACCESS_KEY_ID: "(hidden)"
  - CLOUDFLARE_SECRET_ACCESS_KEY: "(hidden)"
▲ [WARNING] This worker is bound to live services: TEST_SERVICE (test-service#TestService)


[wrangler:inf] Ready on http://localhost:8787
⎔ Starting local server...

✘ [ERROR] The Workers runtime failed to start. There is likely additional logging output above.


If you think this is a bug then please create an issue at https://github.com/cloudflare/workers-sdk/issues/new/choose

✔ script to run › worker:dev-local
$ wrangler dev

 ⛅️ wrangler 3.84.0
-------------------

Using vars defined in .dev.vars
Your worker has access to the following bindings:
- Workflows:
  - SEARCH_WORKFLOW: SearchWorkflow
  - TEST_WORKFLOW: TestWorkflow
- Services:
  - TEST_SERVICE: 🔴 test-service#TestService
- Vars:
  - TURSO_TOKEN: "(hidden)"
  - TURSO_URL: "(hidden)"
  - WEBSHARE_PROXY_URL: "(hidden)"
  - CLOUDFLARE_ACCOUNT_ID: "(hidden)"
  - CLOUDFLARE_ACCESS_KEY_ID: "(hidden)"
  - CLOUDFLARE_SECRET_ACCESS_KEY: "(hidden)"
▲ [WARNING] This worker is bound to live services: TEST_SERVICE (test-service#TestService)


[wrangler:inf] Ready on http://localhost:8787
⎔ Starting local server...

✘ [ERROR] The Workers runtime failed to start. There is likely additional logging output above.


If you think this is a bug then please create an issue at https://github.com/cloudflare/workers-sdk/issues/new/choose

✔ script to run › worker:dev-local
$ wrangler dev

 ⛅️ wrangler 3.84.0
-------------------

Using vars defined in .dev.vars
Your worker has access to the following bindings:
- Workflows:
  - SEARCH_WORKFLOW: SearchWorkflow
  - TEST_WORKFLOW: TestWorkflow
- Services:
  - TEST_SERVICE: 🔴 test-service#TestService
- Vars:
  - TURSO_TOKEN: "(hidden)"
  - TURSO_URL: "(hidden)"
  - WEBSHARE_PROXY_URL: "(hidden)"
  - CLOUDFLARE_ACCOUNT_ID: "(hidden)"
  - CLOUDFLARE_ACCESS_KEY_ID: "(hidden)"
  - CLOUDFLARE_SECRET_ACCESS_KEY: "(hidden)"
▲ [WARNING] This worker is bound to live services: TEST_SERVICE (test-service#TestService)


[wrangler:inf] Ready on http://localhost:8787
⎔ Starting local server...

✘ [ERROR] The Workers runtime failed to start. There is likely additional logging output above.


If you think this is a bug then please create an issue at https://github.com/cloudflare/workers-sdk/issues/new/choose

GitHub

js-rpc-and-entrypoints-demo/public-admin-api-interfaces/db-service/...

Contribute to cloudflare/js-rpc-and-entrypoints-demo development by creating an account on GitHub.

A

Avi•10/30/24, 6:34 PM

is there a way to have a subrequest outlive the parent request in a worker?

A

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

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

A

Avi•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

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

got it!

A

Avi•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.

I think you can bind it directly within that same worker and access it via `env` , here’s a demo: ht

Similar Threads

Similar Threads

Similar Threads