cloudflare / workerd

The JavaScript / Wasm runtime that powers Cloudflare Workers
https://blog.cloudflare.com/workerd-open-source-workers-runtime/
Apache License 2.0
6.07k stars 287 forks source link

🐛 BUG: `wrangler dev --remote` fails with Error 1104, Script not found when using Queue bindings #855

Open AlexDicy opened 1 year ago

AlexDicy commented 1 year ago

What version of Wrangler are you using?

2.6.2

What operating system are you using?

Windows

Describe the Bug

  1. Add a queue binding in your wrangler.toml, in my case:
    [[queues.producers]]
    queue = "emails"
    binding = "EMAILS"
  2. Run wrangler dev
  3. Wrangler outputs: ▲ [WARNING] worker failed to prewarm: Service Temporarily Unavailable
  4. Open http://localhost:8787
  5. The page loads with Error 1104

WRANGLER_LOG=debug wrangler dev does not output any debug info (apart from a .env error) in my case

WalshyDev commented 1 year ago

Trace: /trace/00163570bb46ab64

AlexDicy commented 1 year ago

Still a problem in v2.7.1

estrattonbailey commented 1 year ago

+1 in v2.8.0 on macOS 12.6.1

mrbbot commented 1 year ago

Hey! 👋 I tried to reproduce this and noticed wrangler dev also logs another Queues are currently in Beta and are not supported in wrangler dev remote mode. warning before worker failed to prewarm: Service Temporarily Unavailable. So I guess queues aren't quite supported in the remote dev service. You should be able to use wrangler dev --local for the time being.

estrattonbailey commented 1 year ago

Thanks for looking into it 🙏

Local definitely works, but doesn't have full-API parity with other offerings like Durable Objects, right? Totally fair if that's a compromise we need to make right now. If it's possible, it'd be great for Wrangler to simply ignore queue config locally for now and let the rest of the architecture run as is.

madawei2699 commented 1 year ago

Any update?

penalosa commented 1 year ago

It looks like this should work in local mode (v3's local mode uses the open-source Workers runtime and so has full behaviour parity with Cloudflare APIs like Durable Objects).

However, I'll transfer this issue to the workerd repo to track supporting Queues in the Edge Preview service (wrangler dev --remote)

CharlieBurnett commented 1 year ago

Hey folks!

This is a known issue with Queues and Wrangler and is something we're tracking a fix for on our end.

For now, we recommend using the local dev wrangler env to test out Queues, as the remote dev environment does not function correctly.

Will keep everyone in the loop as this is resolved.

omarkhairy21 commented 10 months ago

Hey, @CharlieBurnett what is the current status of that issue do you still work on it?

a-robinson commented 10 months ago

Sorry @omarkhairy21 , there have been no changes in our (lack of) support for queues in wrangler dev --remote.

NadimHallaq commented 8 months ago

Hey there! Spent hours troubleshooting HonoJS, messing with my setup, even pulled the classic move of deleting and redoing my workers project. Guess what? Turns out Cloudflare queues doesn't support wrangler dev --remote. Just sharing the laughs and lessons learned!

But Seriously tho! I'm already sold on the entire ecosystem, of D1, R2, Workers AI and now Queues so simple and beautiful when it all works together! Any update or workaround on how to run Queues locally?

Any advice is appreciated!

mrbbot commented 8 months ago

Hey! 👋 D1, R2, Workers AI and Queues should be supported when running wrangler dev without the --remote flag. As of Wrangler 3, this runs your code locally using pretty much the same workerd runtime as when your code is deployed. Your code, D1, R2 and Queues run fully locally. Note this means you can't access production D1 and R2 data during development. Workers AI local support proxies to remote models, and still requires a login.

NadimHallaq commented 8 months ago

@mrbbot, many many thanks!

I relied on --remote to avoid manually setting up everything locally, particularly with R2 and D1. I hadn't realized it became automatic in Wrangler 3! Now that I'm running everything locally, it's much cleaner this way.

KrisBraun commented 6 months ago

Hey! 👋 D1, R2, Workers AI and Queues should be supported when running wrangler dev without the --remote flag. As of Wrangler 3, this runs your code locally using pretty much the same workerd runtime as when your code is deployed. Your code, D1, R2 and Queues run fully locally. Note this means you can't access production D1 and R2 data during development. Workers AI local support proxies to remote models, and still requires a login.

I think (based on the docs and some testing) that Workers AI isn't supported locally. So my challenge is there's no configuration that works with both queues and Workers AI.

ChristianJacobsen commented 2 months ago

So my challenge is there's no configuration that works with both queues and Workers AI.

Suffering from the same @KrisBraun, only for me it's cloudflare:email. Hopefully this will be supported when we have GA Queues.

ceddybi commented 2 weeks ago

@AlexDicy @mrbbot @ChristianJacobsen it's easy, you can define two different environments, each with it's own main script pointing to two different workers,

e.g for dev where queues cannot work with --remote, you export everything but queues

[env.dev]
vars = { ENVIRONMENT = "dev" }
workers_dev = true
main = "src/_dev.ts"
// src/_dev.ts

export default {
    fetch: router.fetch,
}

to run dev wrangler dev -e dev --remote


on prod env you export all

[env.production]
vars = { ENVIRONMENT = "production" }
main = "src/_prod.ts"
workers_dev = false
// src/_prod.ts

export default {
    fetch: router.fetch,
    queue: browserQueue,
}

to run prod wrangler dev -e production --local