next/after support and better AsyncLocalStorage context in general

[conico974]

This PR make the AsyncLocalStorage available to the middleware as well as the edge function.

It also provide support for next/after everytime including for lambda. On lambda without streaming it will block the response until all after promise are either resolved or rejected. Tested on lambda with streaming, it works as expected.

It can also be used to emulate vercel request context (the waitUntil) for lib that may rely on it on serverless env. It needs this env variable EMULATE_VERCEL_REQUEST_CONTEXT to be set to be enabled

And for wrapper that has native support for waitUntil they can provide globalThis.openNextWaitUntil ( Should work on cloudflare, not tested though)

I haven't found a way to test this with our current e2e setup, if someone has an idea ?

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 18457d709195b94fc1d329a5614b9a72281203ed

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

| Name | Type | | ---------------- | ----- | | @opennextjs/aws | Patch | | app-pages-router | Patch | | app-router | Patch |

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new[bot]]

Open in Stackblitz

pnpm add https://pkg.pr.new/@opennextjs/aws@626

commit: 18457d7

[khuezy]

oh jeez that's a lot of lint warnings lol

[conico974]

Ho right i missed them, should be good now

[conico974]

@khuezy Yeah it would make sense, but i haven't figured out a way with our current setup. The e2e test on the next repo for this rely on local console.log, which we cannot really use here. Probably something with an endpoint, but haven't figured it out yet

[khuezy]

To truly test after, the page request has to fully terminate, so the ALS would lose context w/ a new lambda... so I think we have to store some flag in DDB or something.

[conico974]

Ho this give me an idea, we create 2 endpoint one that got the after and another one that would be ssg. On the one with after we call revalidatePath in a promise that resolve like 5s in after. We then just need to check if the ssg has changed or not and if the initial call didn't take more than 5s.

This is a bit hacky, but that's the only thing i can think of right now. I'll work on this later tonight

[khuezy]

Great idea, I don't think we'd need 2 endpoints for this. It can just be after/page.tsx where we call

after(() => {
   revalidatePath('/after') // inside 5 second timeout
})
return <>{time}</>

The test would reload the page and check that the time hasn't changed until after 5 seconds... I think that would work? I could be missing something tho. Actually this doesn't work, it's unsupported.