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]

🦋 Changeset detected

Latest commit: 18457d7

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]

Open in Stackblitz

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

commit: 18457d7

[vicb]

Nice!
A couple nits.

[khuezy]

oh jeez that's a lot of lint warnings lol

[vicb]

I think there are still a few instances of __als in the tests

[conico974]

Ho right i missed them, should be good now

[khuezy]

LGTM. Would it make sense to add an e2e test for the next/after stuff?

[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.

[vicb]

Thanks,
only a few very minor things

[vicb]

small nit

Suggested change

	console.log("date", date);
	return NextResponse.json({ date: date });
	console.log({ date });
	return NextResponse.json({ date });

[conico974]

I think i'll remove the console.log entirely, not really useful

[vicb]

Maybe add

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

[vicb]

nit: rename this to waitUntil and change below get: () => ({ waitUntil }) - I feel like introducing a new name is not worth