Routes not working for worker

Hi,
I have deployed two workers with routes and query parameters in the URL through the wrangler GitHub Action. One has been successful and the other hasn’t, despite the same configuration as far as I can tell.

Not-working Worker:
The worker isn’t working with the route that I specify (api.example.com/route1/), but is working with the default Cloudflare-assigned route (the query parameters work and it returns the expected result).
Working Worker:
This is odd because another worker that I have works fine with the route that I have specified (api.example.com/route2/
) and I used exactly the same deployment method (GitHub Wrangler action workflow) and the query parameters are the same.

I have ensured that the two routes are in fact different in the cloudflare dash and that they have been assigned to the correct worker.

This is essentially the deploy.yml file I’m using in each worker:

name: Deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - name: Checkout code
        uses: actions/[email protected]

      - name: Publish
        uses: cloudflare/[email protected]
        with:
          apiToken: ${{ secrets.CF_API_TOKEN }}
          environment: 'production'

And this is the wrangler.toml file:

name = "example"
type = "webpack"
account_id = "ACCOUNT_ID"
workers_dev = true
[env.production]
route = "api.example.com/route1/*"
zone_id = "ZONE_ID"

I have tried deleting the worker and redeploying with a different name but to no avail. It’s confusing because the second example works as expected (and in fact the first example calls the second as it runs the worker script.
Perhaps it’s something to do with the production environment?
I have opened a support case but would like to know if others have experienced a similar issue or if they have any input on what I can try.
Thanks!

Make sure to run wrangler publish with --env production.

Thanks for your reply! Do you know how this could be done through the GitHub Action?

https://github.com/cloudflare/wrangler-action#configuration

Thanks again. According to the docs, my statement of environment: ‘production’ should do the trick. Perhaps there’s something else I’m missing

If you go to your target domain’s workers tab, do you see the route?

Yes, the correct route I’ve specified is visible in the workers tab and in the worker

The workers.dev link works as expected, but the specified additional route does not

I think the last thing to do is make sure the subdomain it’s on is proxied - CF workers can only intercept requests and work if CF is proxying said subdomain.

That’s what’s confusing because I have my api subdomain already setup with CF and working currently with another worker so nothing has changed in that regard

Do you mean these two workers overlap on some urls? I don’t think that works, if so (can’t run two workers on the same route) How many Workers scripts can I have per domain? - #7 by thomas4

They shouldn’t overlap, one worker has the route https://api.example.com/route1/* and the other has https://api.example.com/route2/*.

Not sure what it might be then - maybe someone else here can help, but i’d recommend contacting support. Login to Cloudflare and then contact Cloudflare Support by clicking on the Get More Help button. If you receive an automated response that doesn’t solve your issue, reply back saying you need more help.

1 Like

Thanks Judge, I appreciate your time. I have opened a ticket and have linked this thread for more information. Thanks again

If anyone else has any suggestions of things I may be missing, please let me know. Perhaps there are limits for free accounts that I’m not aware of?
I also experimented with different API-token privileges but this didn’t seem to make a difference.

I’d appreciate any input.

I have narrowed this problem down to the fact that I was calling one worker from within another. Despite the workers having different routes (as above), the only way I could get this working was to use the nested worker’s default URL (example-example.workers.dev) rather than the given URL (despite this working as a standalone API). I’m glad I’ve got this to a working state now but I would rather not have to expose the default URL as well as the given one.
If anyone can advise on how to get the desired behaviour (call the worker API from within the other worker using the given ‘additional’ route? There must be something I’m missing, despite having read the Routes worker docs more than a dozen times now!