You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
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
The text was updated successfully, but these errors were encountered:
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 containswaitUntil
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 asunstable_after
argument) relies on response streamclose
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):
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 forwaitUntil
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
The text was updated successfully, but these errors were encountered: