Use "waitUntil" from within the next code

[SamyPesse]

Is there a way to call waitUntil (https://developers.cloudflare.com/workers/runtime-apis/handlers/fetch/#contextwaituntil) from within the NextJs code?

[dario-piotrowicz]

Hi @SamyPesse, unfortunately currently there isn't 😓

It's not difficult for us to implement (as you can see for example we already have a PR that would implement that: #450), but the team hasn't been able to agree on an API for this

I've been trying to push for a resolution but different opinions combined with non next-on-pages related work has caused this to be put a bit on the back burner, sorry about that, I do need to try to resolve this soon 🙏

[SamyPesse]

Thank you @dario-piotrowicz

That's unfortunate, it could help us save ~300/400ms on some rendering by moving the write to our cache after a response is sent.

Maybe next-on-pages could expose a global __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED that we could access for now (with no expectations of it being maintained).
In the meantime, I'll look at patching next-on-pages for our use to expose something like this.

[dario-piotrowicz]

let me just check again with the team and see if we can agree on something 😓

I'd rather not put some quick hack as implementing in a proper stable way shouldn't actually be much more work compared to any quick hack, sorry I'll try to get this sorted soon 🙇

PS: regarding a patch it should be pretty straightforward to implement but please let me know if you need help with it 🙂

[SamyPesse]

We are using bun and it doesn't support patching yet, so I'll have to create a fork and build it in a git repository, probably using #450

[dario-piotrowicz]

@SamyPesse I've just merged #659 which introduces a new utility (getRequestContext) that gives you access to waitUntil.

You can use it by installing the latest beta release and it will be available in the next stable release we make.

If you want, please give it a try and let me know if that works well for you 🙂

[SamyPesse]

@dario-piotrowicz Thanks! It was quite straightforward to replace our custom patch, it looks like it's working.

The only feedback I have at the moment is that I need to wrap it with a try { ... } catch () {...} for local development because it throws an error instead of returning undefined.

[dario-piotrowicz]

@SamyPesse I'm glad using it wasn't too problematic 🙂

Regarding the need to try-catch it for local development... that shouldn't be necessary... 😕

Have you set up the Cloudflare "platform" for local development in your config file? (https://github.com/cloudflare/next-on-pages/tree/main/internal-packages/next-dev#how-to-use-the-module)

[SamyPesse]

I don't use these steps because we need the next app to be easily deployable both on Cloudflare and Vercel.

Also is it possible to expose request in it?

We currently have to store a cache of pending promise, but to avoid errors like:

Cannot perform I/O on behalf of a different request. I/O objects (such as streams, request/response bodies, and others) created in the context of one request handler cannot be accessed from a different request's handler. This is a limitation of Cloud...

We are trying to use a Cloudflare object as a key in a WeakMap for this cache. (To ensure we share the pending promises only within a single execution).

With our patch, we were using Cloudflare's ctx, but I don't know why. Since we upgraded yesterday to your export, it's not working anymore, and we are getting this error again (it looks like ctx is shared as an object between multiple concurrent executions in a worker).

So request could be a better candidate for this.

[SamyPesse]

The issue is that getRequestContext is recreating a new object at each call :/ instead of returning the same object during the entire execution. (I understand the idea of preventing people from extending it, but it could be frozen for this instead of creating N new objects).

[SamyPesse]

@dario-piotrowicz I'd like your input on something:

We are still facing errors

Cannot perform I/O on behalf of a different request. I/O objects (such as streams, request/response bodies, and others) created in the context of one request handler cannot be accessed from a different request's handler. This is a limitation of Cloud...

The reason is that we have a logic to run an async function only once at the same time it's running (ex, around a fetch). Since Cloudflare Workers handle multiple requests in the JS context, the global variables are shared.

To fix it, I tried to use a WeakMap where the key will be an object unique to the request. Unfortunately, I can't access the request itself to use it as a key, so I was using the result of getOptionalRequestContext(), but since you define a global proxy (

next-on-pages/packages/next-on-pages/src/buildApplication/generateGlobalJs.ts

Line 32 in be1ab75

globalThis[Symbol.for('__cloudflare-request-context__')] = new Proxy(

), it doesn't work (the object is the same for multiple requests in parallel).

Then I tried to use getOptionalRequestContext().ctx, but it looks like it doesn't work either because the Cloudflare ctx is shared between requests?

I'm curious why you are using a global proxy instead of directly accessing the object from the async local storage.
Is it possible to expose the request in it?
If not, what object do you think I could use as something to represent the context of the current request?

[dario-piotrowicz]

Hi @SamyPesse, so sorry for the late reply 🙇

Have you tried getOptionalRequestContext().cf? that I'm pretty sure won't be shared across requests (but it will during local development so keep that in mind 😅)

I'm curious why you are using a global proxy instead of directly accessing the object from the async local storage.

I am not completely sure I follow... we use a global proxy so that we can set it in the worker's template and then we know where to retrieve it from the getOptionalRequestContext implementation. What alternative would there be? we'd have to store the ALS globally somehow anyways no?

Is it possible to expose the request in it?

Yes and no... technically for production it would be a trivial matter, but we'd have to do that also for dev, there things get a bit more cumbersome since we'd have to create requests in Node that would have to match web requests or Miniflare's Request Objects... also the request object (in dev) would always be the same... or we'd have somehow generate it on the fly?... it opens quite a can of warms 😓

[dario-piotrowicz]

Besides the above... this is a complete shot in the dark, but have you tried using Next.js constructs instead? such as cookies or headers?

I wonder if there you do get objects that are tied for the specific request 🤔