-
Notifications
You must be signed in to change notification settings - Fork 168
Make sure next-on-pages can work with Next 15.2 #960
Conversation
🦋 Changeset detectedLatest commit: d053a68 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
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 |
🧪 Prereleases are available for testing 🧪 @cloudflare/next-on-pagesYou can install this latest build in your project with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/next-on-pages/runs/14177289899/npm-package-next-on-pages-960 @cloudflare/eslint-plugin-next-on-pagesYou can install this latest build in your project with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/next-on-pages/runs/14177289899/npm-package-eslint-plugin-next-on-pages-960 |
7a3753e
to
d053a68
Compare
e.message.includes('Disallowed operation called within global scope') | ||
) { | ||
// Next.js attempted to create an AbortController in the global scope | ||
// let's return something that looks like an AbortController but with |
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.
Will this not cause other problems? What if that AbortController is actually needed to clean stuff up? Are we just pushing the issue down the road with this fix? Do we know what AbortControllers are being instantiated in the top level scope outside of a request?
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.
Will this not cause other problems? What if that AbortController is actually needed to clean stuff up? Are we just pushing the issue down the road with this fix?
Yes, that's totally the case, I'm just kicking the can down the road, hoping that this won't cause issues, thinking that we can deal with potential issues caused by this simplified implementation if/when they arise
Given the state of the project and the fact that we're focusing our efforts on the opennext adapter instead I would try not to invest too much time in finding the perfect solution here, just something good enough to unblock people while opennext is still in beta.
I totally understand your concerns though 😕
Do we know what AbortControllers are being instantiated in the top level scope outside of a request?
I am pretty confident that this is due to the fact that (for perf benefits) we dynamically import route functions, in those there are setup steps that create the AbortController
s, these aren't really done outside of the request, but workerd does view them in such a way, this is a workerd limitation that I already in the past flagged to the team: https://github.com/dario-piotrowicz/workerd-dynamic-imports-io-repro
@conico974 made a similar patch for NoW. You can see from the PR he links in the description that the That should not cause any issue. FYI, I'll probably remove the patch from NoW because we do not run user code at top level any more. |
@vicb @dario-piotrowicz @petebacondarwin Thanks for this ❤️🔥. |
resolves #956