Sebastian "Sebbie" Silbermann

Revert "Remove legacy PPR codepaths" (#95113)

fix(incremental-cache): byte-exact fetch cache key for binary bodies (#96008) https://github.com/vercel/next.js/security/advisories/GHSA-4633-3j49-mh5q Co-authored-by: Karim Rahal <karim@karimrahal.com>

[DOM] Scroll to text siblings of empty Fragments instead of the parent (#37060) When a Fragment has no children, React would consider scrolling to siblings first and then to parents. However, React only considered `HostComponent` for the siblings. Since we already have a heuristic for scrolling to `HostText`, we can reuse that same heuristic. --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Validate server reference IDs during manifest lookup (#96007) https://github.com/vercel/next.js/security/advisories/GHSA-955p-x3mx-jcvp Co-authored-by: Josh Story <story@hey.com>

[Fiber] Collect Host Singleton children of Fragments (#37063) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Ensure unique resolved `headers()` value between render passes (#96085) A HTTP request can render the same React tree in multiple passes with different semantics for `connection()`: the prospective and final prerenders of a runtime prefetch, or a navigation's dynamic render and the runtime prerender that is spawned from it to refresh the client's prefetch cache. All of these passes previously resolved `headers()` to the single sealed headers object created lazily by the request store, so userland caches keyed on the identity of `await headers()` (any per-request memoization that treats the headers object as "the request") leaked promises across passes. With this change, every render pass resolves `headers()` to a distinct object over the same underlying data, making "the headers object identifies the request within one render pass" a real contract. --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

[ci] Rebuild sizebot on the GitHub Actions token (#37322) The build size comparison comment was posted by Danger, which authenticated with a personal access token hardcoded in `scripts/tasks/danger.js`. That token has since been revoked, so sizebot has been posting nothing at all (due to e.g. https://github.com/react/react/actions/runs/32181295467/job/95855395224?pr=37315). This change rebuilds it on the short-lived `GITHUB_TOKEN` that Actions mints per run and a new workflow only responsible for rendering untrusted JSON input as markdown in a PR comment. A straight token swap would not have worked. Fork pull requests did receive sizebot comments, but only because the token was in checked-out source: the sizebot job runs on the `pull_request` trigger, where a fork's `GITHUB_TOKEN` is read-only and cannot comment. The comment therefore moves to a new `workflow_run` workflow, `runtime_sizebot_comment.yml`, which runs in this repository with a writable token no matter where the pull request came from. It posts a placeholder when a build is requested and rewrites it in place when the build completes, fails, is cancelled, or is held for maintainer approval. The measurement stays on the unprivileged side of that boundary which are recorded as raw sizes into a `sizebot-results` artifact, and the new workflow downloads only that JSON and renders it from a default-branch checkout. The job holding `pull-requests: write` never unpacks a build produced by a fork, which matters because the existing base-build download justifies using an unverified artifact on the grounds that the job has restricted permissions. Thresholds, the critical bundle list, and the comment template all live on the trusted side, and the renderer validates every field it reads out of the artifact so that a crafted build path cannot inject markdown. The pull request number is resolved from the API rather than from the artifact, since a number read from fork-controlled data would let any contributor post a bot comment on an arbitrary pull request. Resolving that number needs a branch lookup rather than any of the obvious approaches. `workflow_run.pull_requests` is empty for fork runs, and neither `commits/{sha}/pulls` nor the search API indexes fork pull request head commits, so the workflow looks the pull request up by `owner:ref` instead. A comment is only ever left alone in one situation: when it already describes the pull request's current head and the event being handled belongs to an older commit. Everything else is written, and marked stale whenever the report does not describe the current head. That single rule covers both an old run finishing after a force push and a new build superseding a report already on display, and in the latter case the previous numbers stay visible instead of being blanked back to a placeholder. The results file carries a `version` field. Its writer is whatever `compare-sizes.js` a pull request branch happens to carry, while its reader is on the default branch, so the two can mismatch and the renderer needs to be able to say so instead of misrendering a table. Porting the table fixed a longstanding bug in `change()`. Testing `decimal < 0.0001` reported every size decrease as unchanged, which is why `signDisplay: 'exceptZero'` never had a negative number to render: a 709.04 kB to 708.68 kB drop printed as `=`. It now compares the magnitude. Co-authored-by: Claude Code (kimi-k3[1m]) <noreply@anthropic.com>

[next/image]: disable avif image optimization (#97875) https://github.com/vercel/next-js-mirror/pull/160

Consolidate unhandled rejection logging into a single listener (#95999) An unhandled rejection was previously logged by up to three independent process listeners at once: the render runtime's crash-prevention handler in `process-error-handlers.ts` (a bare `console.error`), the router server's `Log.error('unhandledRejection: ', err)`, and the dev server's `logErrorWithOriginalStack`. The runtime handler must exist on every deployment target (#77997), but on self-hosted `next start`/`next dev` it shares a process with the router server's and dev server's listeners, so a single rejection was logged multiple times in different formats. THe first commits adds a test showing the current behavior where we log multiple times. The second commit introduces `registerUnhandledRejectionListener` and `isUnhandledRejectionListenerRegistered` in `process-error-handlers.ts`, and converts the router server and dev server to check-then-register instead of installing their own rejection loggers: - The listener function is shared via a `Symbol.for` key on `globalThis`, so multiple copies of the module (e.g. in the pre-compiled server bundle and in a route module bundle) register and detect a single listener instance. - The registration check queries `process.listeners('unhandledRejection')` instead of a module-global flag, so it stays accurate even after external code calls `process.removeAllListeners`. `installProcessErrorHandlers` therefore calls the register function unconditionally. The `uncaughtException` handlers are left as they are; they have the same duplication and could be consolidated the same way in a follow-up.

Add a script for adopting fork pull requests (#97252) Fork PRs run without repository secrets, so deploy tests never run on external contributions. The workaround is to re-push the contributor's commits to a branch in `vercel/next.js` and open a replacement PR from there, which is fiddly by hand and carries a real security risk. This adds a `pr-adopt` PNPM script to encode the procedure. ```bash pnpm pr-adopt <pr-number> # adopt node pr-adopt <pr-number> --dry-run # report without pushing ``` We copy over the title and body as-is and prepend a `Adopts #N. Closes #N.` line so that the underlying PR automatically closes and we create the proper backlinks. Commits are signed The description is copied rather than rewritten for two reasons: it is the contributor's own text, and any `Fixes #123` inside it has to survive, since the original PR closes unmerged and so never fires its own. ### The confirmation gate Adoption runs the contributor's code on a branch where CI has repository secrets, which is exactly what a fork PR is denied. Anything executing during install, build, or test can read and exfiltrate them, so before touching git the script prints the PR link, status, author handle and association, diff size, and every file touched. Confirming requires retyping the author's handle, and a non-interactive stdin is refused rather than silently proceeding. Two details worth a reviewer's attention: - **The file list is deliberately unranked.** An earlier revision flagged "high-risk" paths (`.github/`, `package.json`, lockfiles). That was removed: a payload can sit in any fixture or source file, and printing "no high-risk paths touched" manufactures false assurance. - **The list comes from the paginated REST endpoint.** `gh pr view --json files` silently caps at 100 entries. #96550 has 106 changed files and returns 100, which would present a truncated list as the complete surface. If the count still falls short of `changedFiles` (GitHub stops at 3000), the shortfall is reported rather than hidden. Draft and closed PRs are both adoptable, since a contributor may still be iterating or may have abandoned an unreviewed change; the status is surfaced rather than enforced. Merged PRs are refused because their commits are already in `canary`.