Skip to content

Comments

[pull] canary from vercel:canary#808

Merged
pull[bot] merged 6 commits intocode:canaryfrom
vercel:canary
Feb 20, 2026
Merged

[pull] canary from vercel:canary#808
pull[bot] merged 6 commits intocode:canaryfrom
vercel:canary

Conversation

@pull
Copy link

@pull pull bot commented Feb 20, 2026

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 : )

lukesandberg and others added 6 commits February 19, 2026 17:25
…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.
@pull pull bot locked and limited conversation to collaborators Feb 20, 2026
@pull pull bot added the ⤵️ pull label Feb 20, 2026
@pull pull bot merged commit 415e0df into code:canary Feb 20, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants