[pull] canary from vercel:canary#808
Merged
pull[bot] merged 6 commits intocode:canaryfrom Feb 20, 2026
Merged
Conversation
…ort on their contents (#89310) Example run ``` $ cargo run -p turbo-persistence --bin sst_inspect -- ~/projects/front/apps/vercel-site/.next/cache/turbopack/v16.2.0-canary.8-207-g8e5467e841e6e-dirty ... Analyzing 169 SST files in /Users/lukesandberg/projects/front/apps/vercel-site/.next/cache/turbopack/v16.2.0-canary.8-207-g8e5467e841e6e-dirty ═══════════════════════════════════════════════════════════════════════════════ Family 0 (Infra): ═══════════════════════════════════════════════════════════════════════════════ SST files: 1, Total entries: 2 Total file size: 44 B Averages: File size: 44 B Keys per file: 2 Keys per key block: 2.0 Per-file Overhead (total): 8 B (18.2% of total file size) Key compression dictionaries: 0 B Average per file: 0 B Block directories: 8 B Average per file: 8 B Block Statistics: Index blocks: 1 blocks (uncompressed), 3 B Key blocks: 1 blocks (uncompressed), 25 B Value blocks: none Entry Type Histogram: type 9: 1 ( 50.0%) │█████████████████████████│ inline 1 bytes type 12: 1 ( 50.0%) │█████████████████████████│ inline 4 bytes Value Storage: Inline: 2 entries, 5 B total ═══════════════════════════════════════════════════════════════════════════════ Family 1 (TaskMeta): ═══════════════════════════════════════════════════════════════════════════════ SST files: 36, Total entries: 8,840,774 Total file size: 670.46 MB Averages: File size: 18.62 MB Keys per file: 245,577 Keys per key block: 1358.2 Per-file Overhead (total): 64.09 KB (0.0% of total file size) Key compression dictionaries: 0 B Average per file: 0 B Block directories: 64.09 KB Average per file: 1.78 KB Block Statistics: Index blocks: 36 blocks (uncompressed), 63.32 KB Key blocks: 6,509 blocks (6,478 compressed, 31 uncompressed) stored: 115.52 MB, actual: 134.92 MB (14% savings) Value blocks: 9,862 blocks (9,046 compressed, 816 uncompressed) stored: 554.75 MB, actual: 673.49 MB (18% savings) Entry Type Histogram: type 0: 8,840,005 (100.0%) │████████████████████████████████████████│ small value (in value block) type 3: 769 ( 0.0%) ││ medium value Value Storage: Small (value block refs): 8,840,005 entries Medium (dedicated blocks): 769 entries ═══════════════════════════════════════════════════════════════════════════════ Family 2 (TaskData): ═══════════════════════════════════════════════════════════════════════════════ SST files: 96, Total entries: 8,840,774 Total file size: 2.60 GB Averages: File size: 27.76 MB Keys per file: 92,091 Keys per key block: 1354.3 Per-file Overhead (total): 253.12 KB (0.0% of total file size) Key compression dictionaries: 0 B Average per file: 0 B Block directories: 253.12 KB Average per file: 2.64 KB Block Statistics: Index blocks: 96 blocks (uncompressed), 63.09 KB Key blocks: 6,528 blocks (uncompressed), 134.84 MB Value blocks: 58,175 blocks (57,911 compressed, 264 uncompressed) stored: 2.47 GB, actual: 5.82 GB (58% savings) Entry Type Histogram: type 0: 8,825,784 ( 99.8%) │████████████████████████████████████████│ small value (in value block) type 3: 14,990 ( 0.2%) ││ medium value Value Storage: Small (value block refs): 8,825,784 entries Medium (dedicated blocks): 14,990 entries ═══════════════════════════════════════════════════════════════════════════════ Family 3 (TaskCache): ═══════════════════════════════════════════════════════════════════════════════ SST files: 36, Total entries: 8,847,914 Total file size: 327.29 MB Averages: File size: 9.09 MB Keys per file: 245,775 Keys per key block: 321.5 Per-file Overhead (total): 2.36 MB (0.7% of total file size) Key compression dictionaries: 2.25 MB Average per file: 64.00 KB Block directories: 107.63 KB Average per file: 2.99 KB Block Statistics: Index blocks: 36 blocks (uncompressed), 268.47 KB Key blocks: 27,517 blocks, stored: 324.57 MB, actual: 495.61 MB (35% savings) Value blocks: none Entry Type Histogram: type 12: 8,847,914 (100.0%) │████████████████████████████████████████│ inline 4 bytes Value Storage: Inline: 8,847,914 entries, 33.75 MB total ```
Co-authored-by: nextjs-bot <it+nextjs-bot@vercel.com>
The Instant Navigation Testing API already uses a cookie to persist lock state across MPA navigations (page reloads, plain anchor links), since window globals don't survive navigation. Rather than maintaining two parallel mechanisms — a window global for SPA and a cookie for MPA — this makes the cookie the single source of truth for all cases. Playwright sets/clears the cookie directly via the browser context, and the client reacts to changes through the CookieStore API's change event. This removes the window.__EXPERIMENTAL_NEXT_TESTING__ global and the page.evaluate() calls that went with it.
Replace the layered abstraction (Meta, MetaFilter, MultiMeta, ExtendMeta, and 12 category component functions across 5 files) with a single flat function that builds a tags array using explicit if-checks and for-loops. Every meta/link tag is now visible as literal JSX at the call site. OG image/video/audio properties and AppLinks fields are enumerated explicitly rather than iterated generically from object keys. Keys are assigned directly on each element at push time, eliminating the cloneElement keying pass.
… runtime (#90205) The unhandled-rejection module was being bundled into server.runtime.prod.js AND loaded as a standalone file, causing installUnhandledRejectionFilter() to run twice. Each instance captured the other's handler as an underlying listener, creating mutual recursion that overflowed the stack on any unhandled rejection. Fix: Rename to .external.tsx so the webpack config externalizes it from the server runtime bundle. It is now only loaded once from the standalone file by node-environment.ts. Also adds two defensive measures: - A global symbol guard that noops if a second installation is ever attempted from a separate module evaluation (e.g. Jest's module system re-evaluating an already-loaded module in the same process) - A reentrancy guard on the handler that noops if an underlying listener synchronously re-emits 'unhandledRejection'
This PR speeds up the `instant-validation` test suite from 450s down to ~100s. We were wasting a lot of time in `waitForNoErrorToast()`, which ends up waiting almost 15s by default. The trick is to add some debug logs inside app-render to track when instant validation started/ended. If we know that the validation is finished, we can just wait for a short time, because if there were errors, a toast would be displayed very quickly. Note that is a stopgap -- when we add a "Validating..." indicator, we won't have to emit the log and can just wait for the indicator instead. But in the meantime, waiting for the tests is pretty painful, so this is worth doing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )