https://vercel.slack.com/archives/C0B0LKK5QD7/p1779825011578549
> I'm not having any luck reproducing this locally, and there's no
useful logs from GitHub Actions. Looking at the timestamps, it
successfully completes `pnpm install` and then hangs for 30m until it
times out.
> I'm not seeing these failures in the `canary` branch, and this only
happens with node 24. I'm just going to disable this job on the
`next-16-2` branch. The failure doesn't appear to be indicative of any
real issue on our end, it's more likely an issue with node or pnpm.
Example failure:
https://github.com/vercel/next.js/actions/runs/26503905088/job/78051437920
This header is used by proxies to perform a concatenating resume render for partial prerendering. It is never sent from the client so we can filter it out when running in a mode that does not have an intermediate proxy.
we have auditing that server files aren't included in client chunks but the new htmlescape usage in next/script is causing that validation to fail. This refactors the utility into lib/shared
props set on a next/script with beforeInteractive are serialized as JSON into an inline script to be exectuted prior to hydration by Next.js. The props were not additionally escaped and if user input was rendered as through a script it could allow fro XSS. This has alwways been true if you pass user input into the script body or via dangerouslySetInnHTML however and it is always the developers responsibility to sanitize user input before rendering. However wherever React has some automatic escaping to act as an additional defense against common mistakes leading to vulnerabilities like XSS Next.js should mirror that becasue from the user's perspective it is not clear that React is not directly rendering the script props and content.
This change adds additional escaping so that serialized properties cannot break out of the script scope and execute unexpected payloads.
Backport #93453 to 16.2
How was this ever working for dev? In that case, `buildId =
"development"` and so it always uses the same cache key
Co-authored-by: Niklas Mischkulnig <4586894+mischnic@users.noreply.github.com>
`pnpm dlx` isn't using a lockfile. Using the self-contained binary from
GitHub and validate the checksum lets us effectively pin `datadog-ci`
and all of its possible transitive dependencies.
This is a follow-up for
https://vercel.slack.com/archives/C0APPN2LC83/p1775073127894859
(cherry picked from commit 631fae951d)
Moves all release workflows off of a GH PAT and uses an app with a
short-lived token instead.
Test Plan:
Dry run
[here](https://github.com/vercel/next.js/actions/runs/24934593874).
However, this workflow is blocked until we figure out commit signing for
the bot app. Some options:
- The bot account generates a signing key and we use it in CI (not
great, bypasses the app)
- The org bypasses signature verification for the bot user (also not
great, requires an exemption rule)
- We need to rework the commit step so Lerna does not do the push, and
instead trigger it via the app + GH API. This seems like the best
option, will be added in a follow-up PR.
Note: `create-release-branch` workflow is broken in its current form, as
we will not be restoring administrator privileges to adjust environment
settings. This will become a manual step in the future.
(cherry picked from commit e69de2ffaf)
Moves the `environment` into `publishRelease` rather than
`trigger_release` since the actual action we want to create environment
rules for is the publish step.
(cherry picked from commit 2b846de4c5)
Switches from a long-lived token to trusted publishing OIDC flow. This requires a bump to Node (for feature support). Otherwise just dropping unnecessary envs.
(cherry picked from commit 129896c2e4)
## Summary
- backport the fallback route params fix from #91737 onto `next-16-2`
- preserve intermediate shells that suspend only for unresolved fallback
params during staged rendering
- add the missing `resolvedRouteParamKeys` request metadata needed by
this branch
Switch CI from self-hosted runners to GitHub-hosted runners and fix the
follow-up issues that showed up once the hosted jobs were exercised.
- Move Linux workflows onto `ubuntu-latest-16-core-oss`, Windows
workflows onto `windows-latest-8-core-oss`, and the native mac release
lane onto `macos-15-intel`.
- Update the reusable build workflow to work in hosted environments by
relying on `runner.os` instead of label string matching, and by removing
the hardcoded `/home/runner` `fnm` path.
- Make Turbo/sccache configuration explicit for hosted runners:
- unify on `vtest314-next-adapter-e2e-tests`
- pass `TURBO_TOKEN` via workflow env/secrets instead of assuming
runner-level env
- switch Turbo cache mode to `local:rw,remote:rw` so jobs still have
local cache behavior when remote cache is unavailable
- Update the `sccache` action defaults/docs to use the hosted-runner
secret setup (`TURBO_TOKEN`) instead of the old self-hosted token
wiring.
- Make Datadog reporting fail open so missing `DATA_DOG_API_KEY` does
not block CI.
- Fix the CLI reserved-port test so it asserts Next’s own `-p 1`
validation instead of failing earlier on hosted Linux due to
privileged-port binding.
- Replace the live `musl.cc` dependency in `native-builder.Dockerfile`
with musl sysroots imported from GHCR-hosted `rust-musl-cross` images,
keeping the existing `/opt/*-cross` layout used by the Linux native
build scripts.
- Fix the macOS native build workaround s so it applies to all
*-apple-darwin targets based on the Cargo target OS rather than the host
architecture, which avoids napi-build injecting the unsupported -Wl
linker arg when @next/swc is linked with rust-lld on hosted mac runners.
Test Plan:
- This PR's CI
- This
[build_and_deploy](https://github.com/vercel/next.js/actions/runs/24865715983/job/72801225722)
job running on every arch
In a deployed environment, `onCacheEntryV2` determines whether a
postponed response is HTML-origin or RSC-origin by checking whether
meta.url ends with `.rsc`.
For some dynamic full-route RSC requests, Next was passing a URL with
query params into onCacheEntry, for example:
`/[tenant]/samples.rsc?nxtPtenant=tenant-x`
Because that string does not end with .rsc, `onCacheEntryV2`
misclassified the request as HTML and treated it as text/html instead of
an RSC response.
This PR normalizes the URL before passing it to `onCacheEntry`, so the
callback receives the pathname rather than the full URL-with-query.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## Summary
- apply the `setHeader` cookie-support patch to direct route module
handlers in `prepare()`
- make `patchSetHeaderWithCookieSupport()` idempotent so both entry
paths can call it safely
- add an adapter-like direct RSC regression test that fails without the
patch
Closes: NEXT-4919
## Testing
- `NEXT_SKIP_ISOLATE=1 NEXT_TEST_MODE=start pnpm testheadless
test/e2e/app-dir/cache-components/cache-components.test.ts -t "should
ignore late setHeader calls for direct RSC handlers after headers are
sent"`
<!-- NEXT_JS_LLM_PR -->
This updates `_rsc` cache-busting param generation to use a stronger
digest so different RSC request variants are much less likely to produce
the same value.
It also updates the related request-validation and injected
resume/instant-test paths so they continue to generate and validate the
same `_rsc` values across client, server, and edge-reachable codepaths.
In a previous PR https://github.com/vercel/next.js/pull/88183, we added
`images.maximumResponseBody` but in only applied to external images.
This PR ensures the same config also applies to internal images.
Sebastian Sebbie Silbermann