## Summary
For context we discovered jobs were not reliably always running in
https://github.com/vercel/next.js/pull/90668 as addapters + turbopack
group ran more tests than just turbopack group.
- Each sharded test sub-job independently fetched test timings from KV
via a turbo task. Because turbo cache keys can vary across job groups
and KV can return slightly different data at different times, the
sharding algorithm produced different test-to-shard assignments across
groups — causing some tests to be missing entirely and others to run in
multiple shards.
- Adds a `--require-timings` flag to `run-tests.js` that fails loudly if
`test-timings.json` can't be loaded from disk, preventing silent
fallback to KV or round-robin.
- Adds a `testTimingsArtifact` input to `build_reusable.yml` that
downloads a pre-built timings artifact instead of fetching via turbo.
When unset (default), existing behavior is preserved.
- In both `test_e2e_deploy_release.yml` and `build_and_test.yml`,
timings are now fetched once in a setup job, uploaded as a GitHub
artifact, and downloaded by all sub-jobs — guaranteeing identical shard
assignments across all job groups.
## Test plan
- [ ] Verify `build_and_test.yml` jobs pick up the shared `test-timings`
artifact
- [ ] Verify `test_e2e_deploy_release.yml` deploy jobs pick up the
shared `test-timings` artifact
- [ ] Verify workflows that don't pass `testTimingsArtifact` (e.g.
`integration_tests_reusable.yml`, `pull_request_stats.yml`) still use
the turbo fallback path unchanged
The recent change to always run all tests without aborting on failure
(#88435) inadvertently broke manifest generation. Previously, test
output was emitted for all tests when `NEXT_TEST_CONTINUE_ON_ERROR` was
set, but that variable was removed. Now test output is only emitted for
failing tests, causing the manifest to lose all passing test entries.
This adds a new `NEXT_TEST_EMIT_ALL_OUTPUT` environment variable that
restores the full output behavior specifically for the manifest
generation workflows.
It's more useful and efficient to run all tests and report all failures
instead of aborting on the first failure. This way, developers get a
complete picture of what needs to be fixed in a single run, and don't
have to go through multiple iterations of fixing one failure at a time.
The file already had the `@ts-check` directive, so the IDE did show errors in that file. But since it was not included in the root `tsconfig.json`, those errors were not reported during CI runs.
One issue found this way was that the `related` flag was defined but never used. The referenced script was removed in #67644.
i got bit by this often :p
<!-- 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:
## For Contributors
### Improving Documentation
- 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
### Fixing a bug
- 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
### Adding a feature
- 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
## For Maintainers
- 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
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
The peerDeps are already bumped to 19.2.0 at
https://github.com/vercel/next.js/pull/84463, but the test/CNA templates
weren't updated as the `syncPagesRouterReact` value is always false at
the moment, which blocked the update.
Therefore, remove the `syncPagesRouterReact` condition to match the
actual peerDeps bump.
---------
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
Co-authored-by: Sebastian Sebbie Silbermann <sebastian.silbermann@vercel.com>
https://github.com/vercel/next.js/pull/83961 lets you run both `next dev` and `next build` at the same time, however it's still problematic to run two instances of `next dev` or two instances of `next build` at the same time with the same `distDir`.
This sort of thing can happen to anyone by accident, but we've seen reports of this sort of behavior with AI agents.
https://github.com/vercel/next.js/pull/84378 adds a lockfile around just the persistent cache database in Turbopack, which helps, but it's not the only reason this is problematic, so we also need a lock around all of Next.js itself.
I was not able to find a cross-platform lockfile implementation in node that I felt was of sufficient quality, so on POSIX platforms this uses the recently-stabilized Rust stdlib implementation, which appears to be derived from rustc's own lockfile implementation, which has seen widespread use/deployment.
On Windows, since we'd rather have an advisory lock than a mandatory one, this emulates that by instead opening a file with write permissions, and a sharing mode that prohibits shared write access. That means that other processes can safely read the (empty) lockfile without blowing up.
<img width="500" src="https://github.com/user-attachments/assets/1ee4a6c6-2280-4f64-8bf2-ec5369c26db1" />
<img width="500" src="https://github.com/user-attachments/assets/2b04b566-c0b4-42ce-af34-912f3f6afa72" />
Tested on Windows as well:
<img width="1224" height="690" alt="Screenshot 2025-10-07 at 5 44 33 PM" src="https://github.com/user-attachments/assets/e36085b6-9c32-40ac-aca6-4c83e2a53842" />
Next.js tests are grouped based on timing data to better distribute them
for parallelization.
Previously this relied on a gist file that we would write to in CI.
However, this has more recently started resulting in 401s.
The actual reason for the 401s is the Turbo task wasn't propagating the
required environment variable to the task. It was mostly working by
accident, because we would store timing data on disk for the runner,
which would have been satisfied by a job that ran before it.
However despite that, relying on a gist file to read/write timing data
didn't feel like the write abstraction. I decided to refactor it to use
KV instead.
This also makes the handling more resilient to missing timing data. We
shouldn't fail the build if we can't fetch timings, as there's already
handling to fallback to round robin.
### What?
Replace LRU cache implementation with an optimized doubly-linked list
algorithm and move from server-only to shared library location.
### Why?
The previous Map-based LRU cache had suboptimal eviction performance for
route matching operations under high load. Route matching is a critical
performance path in Next.js that benefits significantly from true O(1)
cache operations.
### How?
- Implement doubly-linked list with sentinel nodes for true O(1)
get/set/delete operations
- Add comprehensive test coverage including size-based eviction
scenarios
- Update import paths across 14 files throughout the codebase
- Add defensive null checking for edge cases discovered during static
analysis
- Replace deprecated `keys()` iteration with modern `Symbol.iterator`
pattern
It seems too easy to accidentally not pass through `TEST_CONCURRENCY` in `build_and_test.yml`, so IMO `run-tests.js` should use it by default, still allowing overriding with `-c` or `--concurrency`.
I tested by spot-checking CI jobs for log lines like this:
```
Running tests with concurrency: 4 in test mode undefined
```
or
```
Running tests with concurrency: 1 in test mode undefined
```
Our CI runs tests in parallel across multiple groups. We want test groups to all take similar amounts of time to decrease overall latency, and to reduce the chance of test group timeouts in CI.
There's logic here to assign intelligently to groups based on previous test timing information, but if there's no timing information for whatever reason (e.g. we don't currently use timings for rspack/turbopack integration tests), then we were assigning them to groups sequentially.
Because tests with similar paths tend to have similar performance characteristics, it's better to assign every nth test to each group, similar to round-robin assignment.
This PR removed the old overlay including the deprecated `buildActivity`
and `appIsrStatus` options.
Closes NDX-785
Closes NDX-855
Closes NDX-865
Closes NDX-866
Closes NDX-867
Closes NDX-868
- `newDevOverlay: true` by default (enables experimental React builds on
canary until owner stacks progress further)
- `run-tests` now sets the env var for tests that were relying on it for
forking behavior
- PPR runners now run with the flag disabled to help catch regressions
in the old overlay until we remove it
- Fixed a number of tests that had outdated snapshots or missed forking
behavior because they weren't running in CI
- Disabled a test that was failing in Turbopack + Experimental React
that is unrelated to the overlay (see:
https://github.com/vercel/next.js/pull/75989)
---------
Co-authored-by: devjiwonchoi <devjiwonchoi@gmail.com>
Let's see how this affects the failure rate and duration of our tests in
CI.
Test times for any given group might increase a bit, while hopefully at
least increasing the chance that the whole test group succeeds. This
would in theory reduce the number of times we have to re-run a whole
failed test group, which is quite time consuming.
A possible downside of this change is that flaky tests which have a
chance of getting fixed with a better implementation might be harder to
detect.
We already create server source maps in dev by default,
so we should make use of them.
To opt-out, run `next dev --disable-source-maps` instead.
Our internal `next-no-sourcemaps` script is now defunct.
JJ Kasper