If a manual signal handler is registered, SIGINT and SIGTERM should not
be handled by Next.js. This was already the case in the standalone
server.js but was missing here, rendering the env flag useless.
With this fix, the example given in
https://nextjs.org/docs/pages/building-your-application/deploying#manual-graceful-shutdowns
is working (again).
Fixes#56810.
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
When using `experimental.typedRoutes` in conjunction with
`experimental.webpackBuildWorker`, type errors would be erroneously
thrown during build.
This is because the build workers are parallelized between multiple
runtimes (edge, server, client), but the `typedRoutes` is unique to each
`webpackBuild`. The state needs to shared between the different compile
steps for each instance of the types plugin.
This leverages plugin state to keep share the `typedRoutes` state
amongst the different workers.
Closes NEXT-1734
Fixes#58369
This ensures we don't spam build logs with dynamic usage errors or
similar unexpectedly as they can be caught by this worker process
listener but shouldn't be logged.
Closes NEXT-1763
This:
- Sends an hmr sync event so that errors that occur after the initial
hmr connection are sent to the client
- Aligns on `path/to/file.js:line:column` format across error overlay
implementations in the cli and on the web
- Adapts "Module not found" errors from Turbopack to include
Next.js-relevant formatting and documentation links to align with
webpack
Test Plan: Passes 3 tests that were previously failing
Closes PACK-1974
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: Leah <github.leah@hrmny.sh>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What?
When using interception routes & rewrites, on first interception the
router will properly handle the request. But when using the back button
and attempting another interception, it won't work
### Why?
Intercepting routes rely on the accuracy of `nextUrl` -- but when
`ACTION_RESTORE` is dispatched (in the `popstate` event), `nextUrl` is
restored from `url.pathname` rather than the flight router state.
### How?
This uses the `extractPathFromFlightRouterState` util which will
properly handle setting `nextUrl`. This util is also used when creating
the initial router state.
Closes NEXT-1747
Fixes#56072
### What?
When handling a server action, in the non-progressive enhanced case,
React will attempt to parse the request body before verifying if a valid
server action is received. This results in an "Error: Connection Closed"
error being thrown, rather than ignoring the action and failing more
gracefully
### Why?
To support progressive enhancement with form actions, the `actionId`
value is added as a hidden input in the form, so the action ID from the
header shouldn't be verified until determining that we've reached the
non-PE case. ([React
ref](https://github.com/facebook/react/pull/26774)). However, in
https://github.com/vercel/next.js/pull/49187, support was added for a
URL encoded form (which is not currently used, as indicated on the PR).
Despite it not being used for server actions, it's currently possible to
trigger this codepath, ie by calling redirect in an action handler with
a 307/308 status code with some data in the URL. This would result in a
500 error.
### How?
React should not attempt to parse the URL encoded form data until after
we've verified the server action header for the non-PE case.
x-ref NEXT-1733
[Slack
context](https://vercel.slack.com/archives/C03S8ED1DKM/p1700674895218399?thread_ts=1700060786.749079&cid=C03S8ED1DKM)
### What?
A `redirect` that occurs during a fetch action will get a status code of
200, while the redirection logic is handled client-side.
### Why?
In this scenario, the redirect is handled by the client router, so no
`Location` is set on the action response. However for debugging /
logging purposes, it'd be useful to still return the same status code
used in other cases (see #58885)
### How?
Rather than selectively setting the status to 303 in the non-fetch
action case, this always applies it.
Closes NEXT-1745
If a build time fetch cache is present from a previous build we don't
want to unexpectedly use it when flush to disk is set to false in a
successive build as it can leverage stale data unexpectedly.
x-ref: [slack
thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1701266754905909)
Closes NEXT-1750
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What?
Calling `redirect` or `permanentRedirect` with a route handler used by a server action will result in that POST request following the redirect. This could result in unexpected behavior, such as re-submitting an action (in the case where the redirected URL makes use of the same server action).
### Why?
By spec, 307 and 308 status codes will attempt to reuse the original request method & body on the redirected URL.
### How?
In all cases when calling a `redirect` handler inside of an action, we'll return a `303 See Other` response which is a typical status code when redirecting to a success / confirmation page as a result of a POST/PUT.
The other option would be to use 301 / 302 status codes, but since we're already doing a 303 status code [here](https://github.com/vercel/next.js/blob/canary/packages/next/src/server/app-render/action-handler.ts#L603), this aligns the behavior for the route handler case.
Closes NEXT-1733
See also: https://github.com/vercel/next.js/issues/51592#issuecomment-1810212676
[Slack x-ref](https://vercel.slack.com/archives/C03S8ED1DKM/p1700060786749079)
fixes: #58909
x-ref: #58321, #56472, #56231
Removed the Math.round of age since it can cause stale fetch data to be
considered not stale if the age rounds downwards. (5.49 is rounded to 5)
Note: This most likely also fixes some bugs with
revalidateTag/revalidatePath. Tested some tag/path issues that got fixed
with this change.
I think this is because revalidatetag/path sets [data.revalidatedAt =
Date.now()](https://github.com/vercel/next.js/blob/canary/packages/next/src/server/lib/incremental-cache/file-system-cache.ts#L120)
for file-system-cache. And with the current code that value would
continue to be "not stale" for up to 0.499 ms.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
Providing better feedback loop for next bindary.
Some users with old node.js version are seeing `performance` is not defined in #57385, we should check the version first.
For compilation, `performace.mark` will also be compiled after those imports since they're hoisted as ESM. This PR moves performance profiling after the `--help` and `--version` processures and node.js version check. So users can see the "upgrade node.js" hint if the node.js version is too old instead of "performance is not defined"
### What?
When the router action queue receives a bunch of async actions in quick succession, some of those requests are dropped, and as a result, anything observing pending transitions will be stuck in a pending state.
### Why?
When adding items to the action queue, the intended behavior is for new actions to be added to the end of the action queue, to be picked up by `runRemainingActions` once the in-flight action is processed. However, new actions are erroneously overwriting pending actions in the queue rather than appending them, as `actionQueue.last` might have a pending action attached to it.
### How?
This moves the assignment of `actionQueue.last` to always be in `dispatchAction`, rather than the function that processes the action, so that we always have a single spot where `last` is assigned and to prevent it from erroneously omitted/overwritten.
Fixes#59011
### What?
Bump up turbopack which includes url rewrite related improvements. This makes `test/integration/url` test passes.
Note there are some lacking behavior around edge runtime + url behavior, it is being tracked in PACK-2014.
Closes PACK-2051
The rewrite request appear to bypass the `BaseServer` or are executed in
the sandbox. However, these requests have the correct test info in the
headers that can be used instead of the `AsyncLocalStorage`.
Closing: https://github.com/vercel/feedback/issues/47084
- The example previously showed `export const revalidate` being called
from a `utils` file, whereas we want to call it from a route segment
(layout or page)
