Description
We are currently unable to properly support unstable_after due to currently missing functionality in our serverless functions.
Next.js relies on waitUntil implementation being provided - see https://github.com/vercel/next.js/blob/canary/packages/next/src/server/after/builtin-request-context.ts on how to wire it up.
We would need to define globalThis[Symbol.for('@next/request-context')] context which contains waitUntil implementation.
We do currently use some tricks to allow background revalidation (which is similar case of wanting to ensure this finishes executing before lambda stops execution) by keeping connection alive, but this method doesn't play well with unstable_after because one variant of it (when function/callback is used as unstable_after argument) relies on response stream close event (while we attempt to delay it for revalidation).
See those code locations with some wiring for callback variant (there are steps skipped in between - there is quite a bit of "prop drilling" between those):
- https://github.com/vercel/next.js/blob/51d6e76596f42ea51dad6b4bf6fb7817d91a79ec/packages/next/src/server/base-http/node.ts#L166-L168
- https://github.com/vercel/next.js/blob/51d6e76596f42ea51dad6b4bf6fb7817d91a79ec/packages/next/src/server/after/after-context.ts#L95-L98
It does seem to work with doing custom close event emitting (when response is not actually "closed"), but this feels pretty hacky and might have unforseen consequences, so it's just better to wait for waitUntil to be supported in our serverless environemnt instead.
Data
The following is parsed automatically by the Next.js repo e2e test report generator.
test: test/e2e/app-dir/next-after-app-deploy/index.test.ts
reason: unstable_after not supported