Previewing Workers that transform requests, on a real domain

The Workers editor is giving me this banner:

This editor will no longer be supported. Visit the Workers dashboard to use the new editor.

Okay, fine, I’ll use the new editor. Except that when using the new editor, I can’t preview the scripts I’m writing, on real URLs. On the new editor, when I go to the preview, it forces me to view https://{name}.{account}.workers.dev/ (which doesn’t work, because I’m not using that feature). I can’t view https://example.com/route/ to test the script that routes on the URL, using the new editor. If I enter my real domain in, it ignores my input, and puts in the workers.dev one. It’s maddening.

This feature… the ability to preview a Worker script using a LIVE preview of actual URLs on my sites was crucial. I can still use the old editor, for now, but I’m afraid it’s going to go away some day, and I don’t know how I’m expected to develop Workers when I can’t preview them. What’s weird is that I can totally use the “HTTP” tab in the new editor so send preview requests to my actual domain… but i can’t view a preview! When I’m doing content transformation, I’d really like a preview of the site, not a source dump of the HTML.

Am I doing something wrong? Is this a bug in the new editor?

Hi @mark59,

Yes. I can reproduce it, and it is indeed maddening. I’ve filed an internal ticket to get it fixed.

Could you share what browser, browser version, and OS you’re on? That should help us track it down.

Harris

2 Likes

I’m starting to get really annoyed as to how many hoops I have to jump through to get quick and proper debugging with a console. Why can’t we get a list of the domains that the script is deployed to, after we have clicked on the script we want o edit? And a button to reload the script after we’ve wrangler published, without clearing the test-content? Or even better if we could have Test templates that we can apply in the editor, which fills headers, body, url automatically.

Related: Worker dashboard - Feature request: reload script

And no, Cloudworker doesn’t show all of the errors. And no, we can’t catch console and send it to our own logging because stack traces don’t work then, plus we have to use globals for that and it causes multiple console.log on multiple requests to accumulate into large unreadable blobs of text.

Re: the workflow

I am not a real JS dev by any means, so I’m trying to understand the workflow a bit better… but can you use stacktrace.js and then StackTrace.report to send the trace to your logging endpoint?

And then as far as making requests go… I very much like Paw for saving and testing request payloads.

So, theoretically, you do wrangler publish and then run your Paw requests, and StackTrace would send all your errors where you tell it to? With this setup do you even need to jump into their editor?

I’ve looked at different options, tapping into console has been working as long as it’s only single requests and stacktrace.js doesn’t work always, plus it adds 30kb to the script. In any case, try and catch don’t catch all the errors that CF Editor catches, which is why I keep returning to it.

I currently use Paw and would like to catch console and send the stacktrace to my logging, then I wouldn’t need to daffle with the editor.

Still, I see no reason not to improve on the CF Editor.

I’m on macOS 10.15.2 and I was able to reproduce that issue on both Firefox 73.0b2 and Google Chrome 79.0.3945.130.

Thanks @mark59, that did help, by ruling out a couple possibilities of what it could be.

I noticed that I can only reproduce the issue if the new URL has a trailing slash. Does that match what you see?

1 Like

That doesn’t match what I see. For me, any URL that doesn’t start with the workers.dev address gets replaced with the workers.dev address.

Hi @mark59, I’m sorry it took me a while to get back to you.

Assuming you’re still running into this, could you try an experiment?

  1. Enter a URL (without a trailing slash) that typically fails for you.
  2. Click the :arrow_upper_right:[Open in new tab] button to the left of the URL bar.

Does a new tab open? Or does nothing happen? That will help us narrow down where the problem is.

1 Like

If I do not hit return, nothing happens when I click the “open in new tab” button.

If I hit return, it changes to the workers.dev subdomain, and then clicking “open in new tab” opens the workers.dev subdomain, which of course fails, because the worker is not deployed to workers.dev.

And for anyone following along… using Wrangler is by far the superior development experience, which is what I’m now using. So if you’re frustrated by using the web editor, definitely look into Wrangler. It’s great.

2 Likes

Thanks for the information! That helps a lot.

1 Like

Hi @mark59, we found the bug (inadvertently requiring the last character of the URL to be A-Za-z0-9_ in some validation code) and a fix has been released. Thank you for your patience!

1 Like