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

[AlexDicy]

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]

Trace: /trace/00163570bb46ab64

[AlexDicy]

Still a problem in v2.7.1

[estrattonbailey]

+1 in v2.8.0 on macOS 12.6.1

[mrbbot]

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]

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]

Any update?

[penalosa]

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]

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]

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

[a-robinson]

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

[NadimHallaq]

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]

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]

@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]

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]

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]

@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