How to use event.waitUntil in denoflare?

[bebraw]

I am currently trying to implement a small caching proxy on top of denoflare. The idea is to use Cloudflare Images as the origin and then use a Cloudflare worker for using their cache as it's a magnitude cheaper.

I have finished most of the work and now I'm trying to port https://developers.cloudflare.com/workers/examples/cache-api to the scheme. I set up a small example here: https://github.com/survivejs/website-cf-assets/tree/feat/cache-images . See esp. the workers directory. The README contains documentation.

In the code I'm trying to port from, they have a line like this - event.waitUntil(cache.put(cacheKey, response.clone()));. How would you rewrite that in Denoflare?

Right now I'm getting the following error when trying to write to the cache just below the related line:

Error servicing request Error: cloneBodyInit(); bodyInit=object [object ReadableStream]
    at cloneBodyInit (blob:null/fdd64169-1014-473e-ad00-5637d88e3ec2:291:11)
    at DenoflareResponse.clone (blob:null/fdd64169-1014-473e-ad00-5637d88e3ec2:244:38)
    at handleRequest (blob:null/d51faa7f-9dc4-435c-b190-05963ce95746:32:44)
    at async ModuleWorkerExecution.fetch (blob:null/fdd64169-1014-473e-ad00-5637d88e3ec2:400:16)
    at async WorkerExecution.fetch (blob:null/fdd64169-1014-473e-ad00-5637d88e3ec2:500:16)
    at async blob:null/fdd64169-1014-473e-ad00-5637d88e3ec2:2285:30
    at async RpcChannel.receiveMessage (blob:null/fdd64169-1014-473e-ad00-5637d88e3ec2:38:36)
    at async self.onmessage (blob:null/fdd64169-1014-473e-ad00-5637d88e3ec2:2323:13)

The interesting point is that the cloning related error is coming from Denoflare itself. I wonder if has something to do with the fact that I'm dealing with blobs here. Maybe there's some assumption that's biting.

It would be great to hear how you would solve the problem using Denoflare as it seems like a good use case for it.

[johnspurlock-skymethod]

In general, for module-based Cloudflare workers, a third argument context is passed to fetch, which has the waitUntil method. Module-based workers have no event.

Denoflare includes a type called ModuleWorkerContext for this here with an explanation, but it is not Denoflare specific, just providing types for what Cloudflare already does.

I'm assuming you're trying to run this locally via denoflare serve? It should implement that 3rd arg so waitUntil should work in general. Just pass it down from your fetch method.

I think the error you're receiving is cloning the response. Denoflare reimplements Response when running locally, and supports cloning with an ArrayBuffer body, but not a stream (yet). You might try passing the body as an ArrayBuffer on line 49 for now.

I can switch over and try and implement that stream init, how important is it to you to get running locally? For something simple like this, I would just denoflare push it, and add the --watch to autopush on any changes, this way you can test with the real CF cache.

[bebraw]

Thanks, I'll try with the third argument. It would be cool to cover the shape of a worker at the docs.

I think the error you're receiving is cloning the response. Denoflare reimplements Response when running locally, and supports cloning with an ArrayBuffer body, but not a stream (yet). You might try passing the body as an ArrayBuffer on line 49 for now.

I can switch over and try and implement that stream init, how important is it to you to get running locally? For something simple like this, I would just denoflare push it, and add the --watch to autopush on any changes, this way you can test with the real CF cache.

That's a good idea. I'll test this against the deployed version. Having it work locally isn't that important but maybe a good improvement to track.

[johnspurlock-skymethod]

Sounds good - about the documentation, Cloudflare has a page called Migrating to module Workers that talks about the various args to fetch in a module worker.

Where do you think would be a good spot in the Denoflare documentation to have seen this? I don't want to duplicate Cloudflare's docs, since Denoflare is meant to run normal worker code without modifications, so in general any docs about Workers themselves is probably best left to them.

But I could possibly point to some key info in places from the Denoflare docs, the CF documentation is notoriously scattered.

[bebraw]

Where do you think would be a good spot in the Denoflare documentation to have seen this? I don't want to duplicate Cloudflare's docs, since Denoflare is meant to run normal worker code without modifications, so in general any docs about Workers themselves is probably best left to them.

It maybe doesn't need much. In https://denoflare.dev/guides/serve, it would be enough to add the third parameter, link to the doc, and show how to pull the related type. For the type, I ended up using this:

import type { ModuleWorkerContext } from "https://raw.githubusercontent.com/skymethod/denoflare/v0.4.4/common/cloudflare_workers_types.d.ts";

I still don't know how to type BadRequestException, though. I know it's supported by the platform but I don't know where it comes from yet.

It would be cool to dedicate a bit of space in docs for the typing aspect.

[bebraw]

That BadRequestException was something I was able to eliminate. I think it came from some example and it's something unofficial.

I managed to get the cache layer to work though it needs some testing. Thanks for the help.

[johnspurlock-skymethod]

Ah ok, I don't believe I've encountered BadRequestException in the Cloudflare Workers runtime, so it may be something bundled into your worker code. IIRC most of the platform errors follow the FooError javascripty naming convention, not FooException

Glad you're making progress! The Workers platform really makes some interesting stuff possible that is hard/impossible to do elsewhere.