Patch Changes
-
#1488
e6c6736Thanks @vicb! - chore: bump@opennextjs/awsto 4.1.16See details at https://github.com/opennextjs/opennextjs-aws/releases/tag/v4.1.16
- Match
fallback: falseroutes against the decoded pathname. - Do not expose more Next.js internal headers on the middleware response.
- Send the time of entries made stale by a tag to the revalidation queue.
- Do not copy
next.configheaders onto the request headers. - Strip the internal
next-resumeheader from incoming requests.
- Match
-
#1479
223f07fThanks @vicb! - fix: do not serve/cdn-cgi/image/for revalidation requests sent throughWORKER_SELF_REFERENCE -
#1427
2d4665aThanks @jkugsiya! - fix: stop the Durable Object queue from revalidating routes again after every restartOnce a revalidation had failed, the Durable Object queue revalidated the route again every time it restarted, even after the retry succeeded or the queue gave up. The number of extra revalidations grew until the next deployment. The queue now forgets a route once it stops retrying it.
-
#1486
843723cThanks @vicb! - fix: leavecloudflare:*imports external in the server bundlepostgres4 maps its Workers build (src/cf.js) to theworkerdcondition, and that build importscloudflare:socketsstatically. Withpostgres4 inserverExternalPackages, the build failed while bundling the server with:✘ [ERROR] Could not resolve "cloudflare:sockets"cloudflare:*imports are now left to wrangler, asnode:*imports already are, sopostgres4 usescloudflare:socketsin the Worker. -
#1441
7d97fe8Thanks @mathurshubham! - fix: stop the Durable Object queue from skipping ISR revalidations until the next deploymentWith the Durable Object queue, some ISR pages stayed
x-nextjs-cache: STALEuntil the next deployment:- pages that took more than about a second to revalidate,
- pages made stale by
revalidateTagafter their first revalidation.
These pages are now revalidated.
-
#1434
e476844Thanks @mathurshubham! - fix: re-arm the bucket cache purge alarm when the stored alarm is in the pastAffects apps using
purgeCache({ type: "durableObject" })(theNEXT_CACHE_DO_PURGEbinding).Once the purge alarm had exhausted its retries (for example after the
Wrong number of parameter bindingserror fixed in #1289, or a purge rate limit), the Durable Object never scheduled another alarm. Every laterrevalidateTag/revalidatePathqueued its tags but the CDN cache was never purged and pages stayed stale.The alarm is now re-armed when it is in the past. After upgrading, the next revalidation purges the queued tags without having to reset the Durable Object. See #929
-
#1431
8d30187Thanks @kremnyi! - fix: retry all the failed revalidations of the Durable Object queueWhen three or more failed ISR revalidations were waiting to be retried at the same time with the Durable Object queue (
DOQueueHandler), only some of them were retried. The routes that were not retried stayed marked as failed, so later ISR requests for these routes did not trigger a revalidation either. These pages stayed stale until another revalidation failed or the Durable Object restarted.All the failed revalidations are now retried.
-
#1484
b6ccf33Thanks @vicb! - fix: resolve theworkerdbuild of packages from the installednode_modulesinstead of copying itNext.js traces the packages it does not bundle with the Node.js conditions, so the files only used by the
workerdbuild of a package are missing from.open-next. They used to be copied, along with the dependencies of theworkerdbuild, but a dependency that Next.js had partially traced for another package was left incomplete. WithserverExternalPackages: ["@sentry/nextjs"], 1.20.15 and 1.20.16 failed with:✘ [ERROR] Could not resolve "@sentry/server-utils/no-diagnostic-channels"Nothing is copied anymore. The server bundle resolves the packages with a
workerdcondition from the installednode_modules(theworkerdcondition wins over the Node.js ones) and uses the traced copy of a file when there is one, so that each module is bundled once. The files that were not traced are read fromnode_modules.