Cloudflare Developers•3y ago

It’d only be an exception if an unhandled exception occurred

Kkian It’d only be an exception if an unhandled exception occurred

divby0•5/25/23, 1:38 PM

Ohhh okay that makes sense. Thank you very much Kian!

kianOP•5/25/23, 1:39 PM

export default <ExportedHandler> {
  fetch() {
    return new Response(null, {
      status: 500,
    });
  },
};

export default <ExportedHandler> {
  fetch() {
    return new Response(null, {
      status: 500,
    });
  },
};

That'd cause what you're seeing - where the script outcome was okok as it didn't encounter any issues but the response status is 500.

kianOP•5/25/23, 1:39 PM

It's probably an error being try/catched and returning a 500, either by your code or a library

kianOP•5/25/23, 1:40 PM

export default <ExportedHandler> {
  fetch() {
    try {
      throw new Error()
    } catch {
      return new Response(null, {
        status: 500,
      })
    }
  },
};

export default <ExportedHandler> {
  fetch() {
    try {
      throw new Error()
    } catch {
      return new Response(null, {
        status: 500,
      })
    }
  },
};

kianOP•5/25/23, 1:41 PM

If it wasn't in a try/catchtry/catch then you'd get an outcome of exceptionexception

divby0•5/25/23, 1:44 PM

That makes 100% sense. I am using remix and it probably handles that. The reason why I was looking is because I only see stack traces (in the serverside logs) in dev on my laptop, not on prod. I thought the issue is because of cloudflares logging, but it seems to work fine, maybe Remix does weird stuff in prod and not even log the stacktrace

BBjarni (Genki)Hey! I am thinking about using Cloudflare's Constellation to run ML models on C...

Chaika•5/25/23, 4:24 PM

it was increased yesterday to 50 workers-ai

Peter Belbin•5/25/23, 4:50 PM

Can someone provide me with some information regarding what happens as the result of deploying a worker? I'm most interested in what happens regarding a worker that is deployed over top of an existing worker, and what happens to the KV resources that the old assets & KV content that the old worker had.

kianOP•5/25/23, 4:51 PM

KV namespaces aren't linked to any particular Worker. Are you referring to Workers Sites specifically?

Peter Belbin•5/25/23, 4:52 PM

Yes. I have a particular interest in Workers that cache source website responses in KV

Peter Belbin•5/25/23, 4:55 PM

I was wanting to understand particularly what happens to the old KV content when deploy of a new worker happens. I see in Wrangler 1.x that there is some code there that will specifically remove old kv content in conjunction with the old 'publish' command. But, looking at the new Wrangler 3 code, I'm not seeing whether that same behavior exists or not.

DaniFoldi•5/25/23, 4:55 PM

Are you thinking of Workers Sites?

kianOP•5/25/23, 4:56 PM

KV being tied to a Worker is specific to https://developers.cloudflare.com/workers/platform/sites/, a precursor of #pages-discussions used for hosting websites.

kianOP•5/25/23, 4:56 PM

If you just have a Worker that's fetching stuff and putting it in KV, a Worker deploy won't do anything to your namespace's storage

Peter Belbin•5/25/23, 5:04 PM

So, yeah, it's a Workers Sites thing. Front end website is using React, and we have a custom wrangler project that uses @Cloudflare/kv-asset-handler to handle caching in KV, so that custom headers (Content-Security-Policy) and such headers get set before handing to the client the response.

Peter Belbin•5/25/23, 5:07 PM

A while back there were some changes that were made to Wrangler 1.x in regards to causing expiration of KV content to be delayed when a new deployment happens, on the basis, it seems that this would help avoid clients getting HTTP 404 errors. This behavior seems (looking at code for Wrangler 1.x) to be connected with the 'publish' command.

Peter Belbin•5/25/23, 5:09 PM

Am now looking at upgrading to Wrangler 3, but want to understand what the implications regarding KV cache are re when a new 'deploy' happens. Looking at code, I don't really see anything particular happening like it used to with Wrangler 1.x in regards to removal of KV content.

Peter Belbin•5/25/23, 5:12 PM

As a reference point, I'd say that it's fair to say that the existing worker handler takes a lot of inspiration from the example shown at: https://developers.cloudflare.com/workers/platform/sites/start-from-worker/

Start from worker · Cloudflare Workers docs

Workers Sites require Wrangler — make sure to use the latest version.

Peter Belbin•5/25/23, 5:21 PM

https://github.com/cloudflare/wrangler-legacy/pull/2221/files has changes that are related to delaying expiration of previous KV content to allow time for deployments to happen, it seems. It also appears that after this merge, others complained that the mechanism did not work well, and it was reverted to immediately expiring old content.

James•5/25/23, 5:34 PM

Yep, content is just immediately deleted when new content in published when it comes to Sites.

James•5/25/23, 5:34 PM

Your holistic solution here if you don't want to fight with Sites is going to be to migrate to the more managed solution, Pages: https://pages.cloudflare.com/

James•5/25/23, 5:35 PM

Sites works, but it doesn't really get any maintenance or updates these days I'm afraid. Development efforts are focused on Pages.

Peter Belbin•5/25/23, 5:36 PM

Hey James, where exactly is the deletion that you're talking about happening? Are you referring to Wrangler 1.x, or does this also happen with Wrangler 3.x?

Peter Belbin•5/25/23, 5:37 PM

In the Wrangler 1.x codebase, I can see where there is immediate deletion of old, no longer connected KV content in connection with a 'publish', but, Wrangler 3.x seems to not be doing that (or at least, I have not seen where that's happening as yet).

Peter Belbin•5/25/23, 5:39 PM

Could also be that the deletion is happening on the back end without needing to be requested/triggered by the CLI/api, so it might just not be seeable any more.