In #60645, dynamic access tracking was refactored but we erroneously
stopped tracking dynamic access in route handlers. Request proxying, as
well as tracking segment level configs (such as `export const dynamic =
'force-dynamic'`), were only enabled during static generation. This was
an unintended breaking change that consequently caused dynamic access to
not properly bail from data cache in various circumstances.

This adds some more rigorous testing for route handlers, as this seems
to be a fairly large gap in our fetch cache testing currently.

This PR is easiest to review with [whitespace
disabled](https://github.com/vercel/next.js/pull/66446/files?w=1).

Properties such as the native `Headers` / `Cookies` on the `NextRequest`
proxy make use of internal slots, so passing `receiver` (the proxy
object) which does not have the internal slots on it causes an issue in
the edge runtime. Instead, we want to make sure that the target is the
native object. This is similar to
#47088.

<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

Closes NEXT-
Fixes #

-->

### What

* Fix `next/dynamic` with babel config and `src/` directory
* Separate the existing `next/dynamic` dev tests, make it easier to
cover more cases, add `.babelrc` + `src/` folder coverage case

### Why

* The new transform is using `src/` or root dir as the base directory
`next/dynamic` for generating relative module path as unique key for
`next/dynamic` modules. The babel one was always using the root dir
(`cwd`), which is incorrect. It should use the `src/` dir.

In the future we could make the different solution to generate the
unique id simpler, instead of using relative paths

Closes NEXT-3254
Closes NEXT-3251
Fixes #64741

Leveraging the system env vars for fallback logic

x-ref:
https://vercel.com/docs/projects/environment-variables/system-environment-variables

For preview deployment: prefer using `VERCEL_BRANCH_URL`, fallback to
`VERCEL_URL`
For production deployment: prefer using `VERCEL_PROJECT_PRODUCTION_URL`

Closes NEXT-3237

In a previous PR, #47302,
detection for `fetchPriority` assumed that
facebook/react#25927 would land in [email protected]
because that was the react@canary version at the time. However, it
didn't land in [email protected] and it is expected to land in [email protected]
due to the breaking change.

This means that users upgrading to [email protected] will see a warning.

The fix is to stop looking at the `React.version` string and instead
check for `React.use`, a feature that [will land in
[email protected]](https://react.dev/blog/2024/04/25/react-19#new-feature-use)
but is also available in react@canary and react@beta today.

Note: There were tests added for App Router and Pages Router in a
previous PR #47302 but they seem
to run on [email protected] which is why we don't see failures.

Fixes #65161

Fixes NEXT-3498

Fixed loading shows up and disappear during client navigation, when you
defined `prefetch` is enabled and slow `generateMetadata` is defined. In
suspense, adding it back so that the app can still remain suspensy
during navigation.

Prefetch -> Link Navigation -> Show `loading.js` -> RSC payload fetched
(no page content) -> the page content will display later when the
promise is resolved

Prefetch -> Link Navigation -> Show `loading.js` -> RSC payload fetched
-> suspensy page content still triggering `loading.js` -> display the
resolved page content when the promise is resolved

---------

Co-authored-by: Zack Tanner <[email protected]>

When checking which segment(s) need to be refreshed, we currently
compare the current page URL with the segment's refresh marker.

We should inspect the `mutable.canonicalUrl` value first since that's
the URL we're changing to, followed by `state.canonicalUrl` as a
fallback (indicating that there's no URL change pending). This is
because the server action handler will receive a redirect URL prior to
`location.pathname` being updated, so the router will incorrectly think
it needs to refresh the data for the page we're going to.

Closes NEXT-3500

During navigations, the `FlightDataPath` property from the server
response can be an array if there are multiple parallel routes (eg,
`children` and `slot`). When we apply server response to the router
cache, we might call `applyFlightData` for each segment path, which will
copy existing cache values and insert new ones depending on what
changed.

However, the `existingCache` argument that we pass to this function is
the cache at the start of the navigation. That means subsequent calls to
`applyFlightData` will reference the cache _before_ updates are made to
it. This will cause it to erroneously think it needs to lazy fetch for
missing data.

<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

Closes NEXT-
Fixes #

-->

… extension (#66636)

### What

Skip adding trailing slash for file pattern like same origin urls

### Why

Fixes #66635

Next.js will not append trailing slash for file like pattern urls when
`trailingSlash` is enabled. This PR aligns the behavior of the metadata
trailing slash appending with next-server route handling.

---------

Co-authored-by: Jiachi Liu <[email protected]>

While investigating unexpected stale responses when leveraging
`getStaticProps` on the 404 page noticed we have an inconsistency
between local and deployed due to `Cache-Control` being set to
`no-store, must-revalidate` even though a revalidate period is provided.
The inconsistency also differs between the HTML response and the data
response `_next/data` which causes even more unexpected behavior. To
avoid this behavior, this replaces the handling to ensure we honor the
originally provided revalidate period during `notFound: true` for the
`Cache-Control` header.

Validated against provided reproduction here
https://github.com/fusdev0/next-notfound-revalidate
Deployment:
https://vercel.live/link/next-notfound-revalidate-govzskknf-vtest314-ijjk-testing.vercel.app/fallback-blocking/fasdf

Prior PR for prior context that introduced this
#19165

x-ref: [slack
thread](https://vercel.slack.com/archives/C0676QZBWKS/p1717492459342109)
# Conflicts:
#	packages/next/src/server/base-server.ts

Use `addDependency` to track the file path passed to
`next-metadata-route-loader`

NOTE: We cannot apply the `next-metadata-route-loader` directly to the
metatda convention source files, since the json file could be processed
by json loader (Related previous fix #62615)

Previously when we passed down the file path as argument to the loader,
which sort of breaking the caching of webpack as the actual resource
path is string, it's not tracked as a dependency. This change fixed the
bad caching issue of static metadata routes. Based on the above reason
we use `addDependency` here to track the dependency change

Closes NEXT-3521
Closes #65755

As discussed this adds handling to timeout at a max of 500ms for fetch
cache request and retries a max of 3 times due to network instability.
This also adds cache service tests and fixes a case we've been trying to
track down where we were seeing `undefined` cache URL values which made
debugging fetches tricky.
# Conflicts:
#	packages/next/src/server/base-server.ts
#	packages/next/src/server/lib/incremental-cache/fetch-cache.ts
#	packages/next/src/server/web/spec-extension/unstable-cache.ts

…66755)

Closes [#66650](#66650)
Closes NEXT-3520

- Make Link not throw during prefetch if it received an invalid `href`
(see [#66650](#66650))
- Throw in dev mode if an invalid link was passed to `router.prefetch`
-- this matches current prod behavior
- (previously, we'd immediately exit out of `router.prefetch`, so the
user would see no indication that this'd fail in prod)

If an invalid URL was passed to `<Link>`, the whole app would crash and
show "A client-side exception occurred". A failed prefetch should not
bring down the whole app.

Note that This preserves the current behavior of explicit
`router.prefetch(url)` throwing an error if `url` is invalid. We may
want to adjust this in the future, but that could be considered a
breaking change, so I'm leaving it out for now. This only affects
`Link`, which was intended to catch any errors thrown from
`router.prefetch`, but that bit was accidentally broken.