-
Notifications
You must be signed in to change notification settings - Fork 95
feat: support after() #2717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support after() #2717
Conversation
d3d3f98 to
5cc78cf
Compare
📊 Package size report 0.03%↑
Unchanged files
🤖 This report was automatically generated by pkg-size-action |
a86b52d to
a5e4dc4
Compare
cc72e89 to
1cd01a5
Compare
…ions installation time making it timeout
| // Next.js relies on `close` event emitted by response to trigger running callback variant of `next/after` | ||
| // however @fastly/http-compute-js never actually emits that event - so we have to emit it ourselves, | ||
| // otherwise Next would never run the callback variant of `next/after` | ||
| res.emit('close') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is to support callback variant of after():
after(async () => {
// this will not start executing immediately - instead this function will be stored to and start executing after response was ~sent
// make sense to not compete for any resources while working on response and delay executing this function to after that
})
This is not needed to support promise variant like so:
after(new Promise(resolve => {
// this starts executing immediately and will ensure it will finish as long
// as function timeout is not reached
})
| }) | ||
| test( | ||
| 'yarn monorepo multiple next versions site is compatible', | ||
| { retry: 0, timeout: 1_000 * 60 * 5 }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this change just bumps/sets timeout - we have 3 extensions being installed which we don't even use because site is in Netlify-testing account and that's pretty slow and this test case in particular was already slow before, but those 2 things combined meant that it was always timing out now
orinokai
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Feels nicely abstracted in the createRequestContext function 👍🏼
Description
This provides
waitUntilimplementation that Next.js will use forafter()feature. Ifcontext.waitUntilis defined (it's conditionally available now depending on rollout) we will use just that. If it is not defined - we will use our TransformStream trick with keeping response open while awaitingafter()(and other background work) to finish.Documentation
Tests
Test added as second commit - fails without making any changes and work with code changes.
The test use similar setup as Next.js e2e
aftertest - https://github.com/vercel/next.js/blob/canary/test/e2e/app-dir/next-after-app-deploy/index.test.ts and uses 2 pages:/after/check- cacheable page that renders timestamp/after/triggerwhich is SSR that usesafter()to invalidate/after/checkpageFirst we hit the
/after/checkand will get immediately stale content and regenerate it in background getting fresh timestampThen we hit that page twice again making sure we get stable timestamp in both hits
Then we hit
/after/triggerwhich should invalidate/after/checkifafter()is allowed to fully executeThen we hit
/after/checkagain and compare timestamp to timestamps we saw before invalidating it - timestamp now should be greater than beforeRelevant links (GitHub issues, etc.) or a picture of cute animal
Closes #2695