`wrangler dev` in 11.0 is non-functional when there are deployed workers with non-specific routes

[TehShrike]

🐛 Bug Report

I have a worker deployed with a very broad/non-specific route, *example.com/*. It handles some generic redirect behavior.

I have other workers with more specific routes, e.g. https://subdomain.example.com/path/*.

This works fine, thanks to Cloudflare Workers' route matching behavior where the most specific routes are matched first.

However, as of wrangler 11.0, I am unable to test my workers with more specific routes. I run wrangler dev and everything starts up fine, but when I make GET requests to http://127.0.0.1/path/anything, those requests are handled by the *example.com/* worker in production.

This is a bug. At the very least, the route matching rules should be applied, using the route/routes in my wrangler.toml file.

This is concerning. It makes me very nervous that my HTTP requests to 127.0.0.1 could be handled by production workers. This implies that if I'm POSTing to localhost with a valid Authorization header, I could be causing side effects in production.

I do not want/expect requests to localhost to be proxied to unrelated deployed production code.

Environment

• operating system: macOS
• output of rustc -V: -bash: rustc: command not found
• output of node -v: v14.8.0
• output of npx wrangler -V: 👷 ✨ wrangler 1.11.0
• contents of wrangler.toml

Steps to reproduce

What did you expect to see?

What did you see instead?

[caass]

I think this is related to an issue I'm getting, so I'll comment here to avoid opening a duplicate issue.

Steps to reproduce:

1. Create a new wrangler project with wrangler generate example https://github.com/cloudflare/worker-template
2. cd in, populate account_id in wrangler.toml
3. Run wrangler dev, observe that it works
4. Add a route to wrangler.toml that includes a wildcard (e.g. route = somesite.com/*)
5. Add the zone_id for that route, and set workers_dev to false
6. try wrangler dev again
7. Get some output similar to this:

Error: error sending request for url (https://somesite.com/cdn-cgi/workers/preview/?s0=ARPdR5deFqRukgETnkKjn5kSzdo_snRbbMwyeEOIOFMYvs1rH2YrzgvNFKyZQ15Gs6UCiPoylQhuLz_HH692NucZ9_lTDjFeLW5zVueo3fVZQIDl7LgnfW-jQlmD12VveT96NH_KMGy0z6SRtZZmcwy7rWDJs3HaWQqriG6mEyN10p7fyXIsMln87fZM6zKOo-oClrM-iKoq9iCBDVO06NG535432I0gxndTxmWxTY-5NI8MOEgUW5DVur8AGJ-xBSrMoq7JYCKEUHVM2Rww9I3rgOvRWy0PfS4gTEFX7RJv): error trying to connect: dns error: failed to lookup address information: nodename nor servname provided, or not known

This happens whether the route or routes key is specified.

Expected Behavior

I suppose it should look something like this:

• Worker starts up
• For subdomain pattern matching (e.g. *.somesite.com), i feel like it's the responsibility of the user to use something like dnsmasq to forward arbitrary domains to localhost or whatever IP workers dev is running on. I think the request intercepted will have that domain attached to it so the worker can run its "should i execute" logic on it
• For path matching (e.g. somesite.com/*), it's already possible to route requests to (for example) 127.0.0.1:8787/foo, and in fact without a route specified this is the default behavior -- all requests to the ip:port the worker is running on are intercepted, regardless of the path.

I mean basically the expected behavior is what already happens when no route (workers_dev=true) is specified. If I were to speculate, I think the "frontend" for this already works -- workers can already spin up and catch requests to any path on their port, and while I haven't tried it, I suspect the dnsmasq technique works as well. I think it has to do more with the "backend" part, where the worker is actually created based on a route.

[TehShrike]

@caass for thoroughnesses sake, what is your expected behavior after step 4, and what are you seeing instead of that?

[caass]

@caass for thoroughnesses sake, what is your expected behavior after step 4, and what are you seeing instead of that?

@TehShrike I edited my comment to put the expected behavior, as well as what actually happens :)

[ashleymichal]

note: status - needs repro indicates that we'd like a member of our team to reproduce; thank you for the detailed report!

[emesterhazy]

Thanks for posting this @TehShrike - I have the same issue as you. I can't test workers that match on subdomains with dev because all requests to localhost are forwarded to the production server for the bare domain.

[lid]

I have this issue as well; looks like a workaround is to set workers_dev = true in wrangler.toml - in this case the worker will respond, and prevents the request from being forwarded to the production server for the bare domain.

[jamesarosen]

I have this issue as well; looks like a workaround is to set workers_dev = true in wrangler.toml

With [email protected], I've found I also need to delete the route or routes in wrangler.toml. It's annoying to have to make those changes when developing locally then revert them before publishing.

[TehShrike]

Any update on this? This is still killing us when trying to develop workers. Why was #1623 closed?

[quarties]

same issue macOS 11.4 / wrangler 1.17.0 (I also tried latest beta) / node v14.17.0

reverting to 1.10.X fixes it, but I would like to avoid using legacy verions 😞 any news on this?

my wrangler.toml

# top level configuration
type = "javascript"
account_id = "xxx"
zone_id = "xxx"
usage_model = "bundled"
name = "woocommerce-product-cards-staging"
route = "woocommerce.staging.livechat.expert/*"
kv_namespaces = [
    { binding = "STORES", id = "xxx", preview_id = "xxx" },
]

[build]
command = "npm run build"
[build.upload]
format = "service-worker"

[dev]
ip = "127.0.0.1"
port = 8080
local_protocol="http"
upstream_protocol="https"

# environment configuration
[env.production]
workers_dev = true
name = "woocommerce-product-cards"
route = "woocommerce.livechat.expert/*"
kv_namespaces = [
    { binding = "STORES", id = "xxx" },
]

[danbars]

Any news on this? Still happens with wrangler 1.19.6 As mentioned by @jamesarosen it is still needed to comment-out route and set workers_dev to true every time you develop locally.

[jgentes]

@danbars do you see this while using Miniflare?

[danbars]

@jgentes I don't use Miniflare. It started once I've defined a route on my custom domain. The route that I've defined ends with /*.

[jgentes]

Could you try https://github.com/cloudflare/miniflare to see if that is a viable workaround?

[jspspike]

Thanks for reporting this issue! Wrangler v1 is now deprecated and support is only being provided for critical updates or security concerns. As such, we are closing this issue. New versions of Wrangler are maintained in the workers-sdk repo. If you are running into a similar issue with wrangler v2, please report it in the workers-sdk repo. For more info about wrangler v1 deprecation, please check out our blog post.