[pull] canary from vercel:canary #608

pull · 2025-03-01T04:13:16Z

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.1)

Can you help keep this open source service alive? 💖 Please sponsor : )

Reverts #77830 This was breaking the react 18.3 tests, where the toggling stack frames is not working in 18.3. Possibly broken by the ref related changes. x-ref: https://github.com/vercel/next.js/actions/runs/14274082641/job/40015934515

Adds the cache tags to the segment prefetch requests so that they can be invalidated correctly.

This adds an unstable option to the Link component's called `unstable_dynamicOnHover`. When set to true, the Link will initiate a dynamic prefetch as soon as the link is hovered. This is roughly equivalent to updating the prefetch prop to `true` inside a mouse event handler. Because this results in dynamic prefetching, semantically it has the same implication as `prefetch={true}` — by the time the navigation occurs, the target page's data may be slightly stale.

This auto-generated PR updates the production integration test manifest used when testing Turbopack.

### Why? The font ligatures on code frames like `!==` may negatively affect the users by the readability and inconsistency with their editor. | Before | After | |--------|--------| | ![CleanShot 2025-04-05 at 18 57 57@2x](https://github.com/user-attachments/assets/ac4e4dc0-934a-4422-8006-3cd29726d48c) | ![CleanShot 2025-04-05 at 18 58 20@2x](https://github.com/user-attachments/assets/2fe497d5-fe21-4255-91f5-b3bf917df4ba) |

…ts (#77892) Preparation for removing `process.env.TURBOPACK` being added to Turbopack tests. That way we can properly test `next start` without `process.env.TURBOPACK` being set.

#77894) Handles `IS_TURBOPACK_TEST` like if you passed `--turbopack` to `next dev` or `next build`. Doesn't set it for `next start` in order to find bugs where Next.js relies on `process.env.TURBOPACK` at runtime.

…check file existence (#77863) ### Why? The Next.js TypeScript plugin was doing a workaround for updating the virtual file with `deleteFile()` then `createFile()` since `updateFile()` failed even though `env.sys.fileExists()` passed. It is because the system was created based on the FS system via `createFSBackedSystem()`, which falls back to read from the actual file system if the file doesn't exist on the current virtual file system. https://github.com/microsoft/TypeScript-Website/blob/9d447358e4fc67c881202fb40115cd8adf70daad/packages/typescript-vfs/src/index.ts#L544 ![CleanShot 2025-04-05 at 17 39 35@2x](https://github.com/user-attachments/assets/96b3ec2e-3b6d-407d-877f-bdd3224b156b) ### How? Use `getSourceFile()` to check if the file actually exists. This is what`@typescript/vfs` uses to check before running the `updateFile()`. https://github.com/microsoft/TypeScript-Website/blob/9d447358e4fc67c881202fb40115cd8adf70daad/packages/typescript-vfs/src/index.ts#L83-L87

…on (#76993) When running a server action, we want `requestStore.phase` to be set to `'action'`, because it makes `cookies()` mutable. However we were doing this in a pretty coarse-grained manner -- it was set at the beginning of `handleAction`, but wasn't always properly cleaned up in case of early returns that don't render anything (e.g. `{ type: 'not-found' }`). This PR fixes that -- we only set the phase to `'action'` while the action is running, and immediately switch it to `'render'` when it settles. Incidentally, early 'not-found' returns from `handleAction` are currently bugged (see #77012 for more context + fix), so we were also accidentally allowing mutatating cookies while rendering a response to an unrecognized action, which should be a 404, but is currently a 200 + a page render. but that's such a niche edge case that it's not really relevant to real usage.

This test is flaky in headless mode but passing in browser mode. It was timeout on checking the toast. Adding an assertion for it seems resolve the issue

- Fix failures in #77871 that introduced by rspack-contrib/rspack-plugin-react-refresh#22 (comment) 🤦 - Align the inject entry logic with webpack - Use eval-source-map for rspack (before use source-map due to a rspack bug #75981 (comment)) - Temporarily remove source-map ignoreList for rspack (will add it back once rspack has built-in support)

[diff facebook/react@040f8286...33661467](facebook/react@040f828...3366146) <details> <summary>React upstream changes</summary> - facebook/react#32823 - facebook/react#32822 - facebook/react#32825 - facebook/react#32821 - facebook/react#32819 - facebook/react#32816 - facebook/react#32815 - facebook/react#32812 - facebook/react#32762 - facebook/react#32808 - facebook/react#32807 </details>

this is a pure rename, with no behavioral changes. `getServerActionMetadata()` only checks if something: - is definitely a fetch action (sent from the router, with a 'Next-Action' header set) - is *potentially* a no-js action (a multipart POST where we need to run decodeAction to check) so `isAction` is a bit misleading. I've renamed it to `isPossibleServerAction`, and updated related names in other places accordingly.

…hing (#77691) Fixes [#PACK-4425](https://linear.app/vercel/issue/PACK-4225/capacity-exceeded-error-in-qfilter) * Updates the `qfilter` package to use the newly fixed version [with the upstream PR here](arthurprs/qfilter#9).

As of #77894, there's a new way to indicate Turbopack should run, which breaks flaky tests detection with Turbopack. This swaps out the flag to unblock my downstack PR.

@samcx

# Summary The [Geist Fonts](https://vercel.com/font) in [default-tw template](https://github.com/vercel/next.js/tree/canary/packages/create-next-app/templates/default-tw) doesn't load due to missing classname declaration. This PR fixed this issue. ## Before ![before](https://github.com/user-attachments/assets/c45f1b9d-6141-485e-bff1-ec0f7f03f7e8) --- ## After ![after](https://github.com/user-attachments/assets/6bafab0f-a8e7-4df7-a31f-0a27b252bb8b) CC: @samcx --------- Co-authored-by: JJ Kasper <[email protected]>

This auto-generated PR updates the development integration test manifest used when testing alternative bundlers.

This auto-generated PR updates the production integration test manifest used when testing alternative bundlers.

…#77806) This: - Removes the Rspack canary gate - Adds a warning that Rspack support is driven by the community and is experimental. - Links to the discussion page for feedback Test Plan: Installed and used in an app. Verified the link is valid.

This PR updates deps to `[email protected]` to fix few bugs we found: - lovell/sharp#4277 - lovell/sharp#4328 See the full list of changes here: lovell/sharp#4248

This auto-generated PR updates the development integration test manifest used when testing Turbopack.

This auto-generated PR updates the production integration test manifest used when testing alternative bundlers.

This auto-generated PR updates the development integration test manifest used when testing alternative bundlers.

this fixes an annoying issue where `eslint-plugin-next` causes a bunch of typescript errors after a `pnpm clean`. the reason for this was that it didn't have a `"dev"` script, so `pnpm dev` ignored it, and so it never got built at all.

This PR modifies the AMP HTML testing util to avoid loading the validator from the network, which causes random test flakiness. I've also made it use the validator from `next/dist/compiled` to match what we do during builds. This means we can drop `amphtml-validator` from the root package.json.

rip. you served a purpose once, but now you're just getting in the way. this improves typesafety quite a bit, because `BrowserInterface` had a whole bunch of random `any`s everywhere also - removes `evalAsync`. no idea why that was needed, but we're happily using promises in normal eval, so it can be dropped - adds more safety to `chain`

This is one of the intial migrations for #77740 which starts by adding the `handler` signature for pages API routes. This new `handler` signature will be added for all route types and allows a consistent way to invoke entries. This also aims to align all logic to no longer be special cased between minimal mode, standalone mode, and just normal `next start`. All modes will behave and process requests the same at the entry level after this is done. Once all route types are migrated `next-server`, `web-server`, and `base-server` will no longer be necessary and a minimal matching layer will be provided to process rewrites/dynamic routes to the related entry instead. The changes here we validated against the `vercel/vercel` [test suite here](vercel/vercel#13231) and --------- Co-authored-by: Sebastian Sebbie Silbermann <[email protected]>

This updates our matcher handling for middleware to ensure we check encoded/decoded versions of the pathname since the regex will most often not handle all encoding variations. This matcher change only affects public/static files as pages/API routes doesn't allow mismatching encoding.

Our encoding test in `vercel/vercel` started failing from #77994 this reverts part of the change there to ensure we always normalize our dynamic route params. Validated in vercel/vercel#13259 <details> <summary>test failure</summary> ![CleanShot 2025-04-12 at 11 10 48@2x](https://github.com/user-attachments/assets/9696ae4a-8db1-420b-8bc6-ba3e43efb1b1) </details> x-ref: [slack thread](https://vercel.slack.com/archives/C02CDC2ALJH/p1744481510502349)

The notify crate requires handling rescan events with the event queue overflows. Context on this issue in the notify crate: - notify-rs/notify#412 - notify-rs/notify#434 - notify-rs/notify#435 In our case, that means we should invalidate every file we've read in `turbo-tasks-fs`. We should also attempt to re-add filesystem watchers for every path, since some of those paths could've been removed and re-added. Tested this on Linux by lowering the inotify queue to something tiny to trigger frequent rescan events: ``` echo 3 | sudo tee /proc/sys/fs/inotify/max_queued_events rm -rf /tmp/fuzz && RUST_BACKTRACE=1 cargo run -p turbo-tasks-fuzz -- fs-watcher --fs-root /tmp/fuzz --notify-timeout-ms 100 --directory-modifications 0 echo 16384 | sudo tee /proc/sys/fs/inotify/max_queued_events # restore back to default ``` As a sanity check, I also tried running the fuzzer on macos, though it doesn't seem like there's as easy of a way to trigger rescan events on that platform (?).

#76234) ### What? Instead of collecting all modifications to the task graph in a log structure (which ends up taking a lot of memory), use a modified and snapshot flag to avoid using more memory than needed. This way we don't store extra memory before a snapshot is requested. Once a snapshot is captured, we store at most twice the memory. We store only the memory of the modified tasks. It works this way: Idle Phase: (before a snapshot is requested) * When a task is modified, we only set the modified flag on that task. Capturing a snapshot want to avoid locking all tasks. So it first switches to the Snapshot Phase. Snapshot Phase: (after a snapshot is captured) * When a task is modified: * If there is already a snapshot, skip * If the task has the modified flag set, clone the task and store the snapshot. * If the task doesn't have the modified flag set, store a None snapshot. To actually capture the snapshot, go over all modified or snapshot tasks (which is stored in a separate map): * If the task has a snapshot (not None) stored, use that. * If the task has only the modified flag set, read the task state and capture a snapshot from that. * There is a race condition here, when the task is modified inbetween. We handle that by having a snapshot flag too. We have all snapshot captured now. To leave Snapshot Phase, we * First unset all modified flags. * Switch to Idle Phase. * Change all stored snapshots to modified.

This commit adds an `onInvalidate` callback to `router.prefetch()` so custom `<Link>` implementations can re-prefetch data when it becomes stale. The callback is invoked when the data associated with the prefetch may have been invalidated (e.g. by `revalidatePath` or `revalidateTag`). This is not a live subscription and should not be treated as one. It's a one-time callback per prefetch request that acts as a signal: "If you care about the freshness of this data, now would be a good time to re-prefetch." The supported use case is for advanced clients who opt out of rendering the built-in `<Link>` component (e.g. to customize visibility tracking or polling behavior) but still want to retain proper cache integration. When the callback is fired, the component can trigger a new call to `router.prefetch()` with the same parameters, including a new `onInvalidate` callback to continue the cycle. (For reference, `<Link>` handles this automatically. This API exists to give custom implementations access to the same underlying behavior.) Note that the callback *may* be invoked even if the prefetched data is still cached. This is intentional—prefetching in the app router is a pull-based mechanism, not a push-based one. Rather than subscribing to the lifecycle of specific cache entries, the app occasionally polls the prefetch layer to check for missing or stale data. Calling `router.prefetch()` does not necessarily result in a network request. If the data is already cached, the call is a no-op. This makes polling a practical way to check cache freshness over time without incurring unnecessary requests.

The prefetch scheduler limits the number of concurrent prefetch requests, to avoid saturating browser's internal network queue. As a starting point, I had previously hardcoded this to 3 — intentionally stingy, to leave room for additional optimizations. In this PR, I allow the most recently hovered link to exceed the default limit. This increased limit only applies to the *most recently* hovered link; if a different link is hovered, the previous one is bumped back down to the default. The principle is that when hovering over a new link, we should have enough bandwidth to start prefetching its data. (In practice, because we don't cancel in-progress requests, it's still possible that we'll fill up the queue, but this makes it less likely.) As part of this change, I changed the implementation of the internal Intent priority level. Intent used to assigned to any link that was ever hovered over; it would never get bumped back down to Default, even on mouseexit. This was intentional at the time, but given this new optimizaiton, it makes more sense to downgrade previously hovered links to free up the bandwidth.

### What? Updates the `userAgent` middleware example in the documentation to accurately reflect all possible values of `device.type` and demonstrate proper handling of desktop browsers (undefined case). ### Why? The current example shows a binary mobile/desktop check which doesn't accurately reflect the API's capabilities. The `device.type` property can actually return multiple values ('mobile', 'tablet', 'console', 'smarttv', 'wearable', 'embedded', or undefined), but the example only shows handling of 'mobile', which could mislead developers. ### How? - Updated both TypeScript and JavaScript examples to: 1. Add comprehensive comments documenting all possible `device.type` values 2. Use proper undefined handling with the OR operator for desktop browsers 3. Maintain consistency between TS and JS versions 4. Better align with the documented behavior in the API reference - Ran `pnpm prettier-fix` to ensure proper formatting - Followed the [Docs Contribution Guide](https://nextjs.org/docs/community/contribution-guide) The changes help developers better understand: - The full range of device types they can detect - How desktop browsers return undefined - The proper way to handle device type detection - Consistency with the rest of the API documentation ### Checklist - [x] Read the [Docs Contribution Guide](https://nextjs.org/docs/community/contribution-guide) - [x] Ran `pnpm prettier-fix` to fix formatting issues - [x] Ensured examples are clear and follow documentation best practices - [x] Maintained consistency with existing documentation style - [x] Verified the accuracy of the technical information --------- Co-authored-by: JJ Kasper <[email protected]>

@lukesandberg

I thought this was already here, but @lukesandberg pointed out it wasn't. I'm pretty sure we're doing transmutes in a few places that assume this, so we should have it. There's likely no change in behavior: The only sane memory layout for these types is the transparent one, but the annotation guarantees it for our unsafe code.

This pull request introduces changes to enhance the handling of prefetch segment data routes in the Next.js build process and adds new test cases to validate these updates. Key changes include the addition of a new `buildInversePrefetchSegmentDataRoute` utility, modifications to the route generation logic, and the introduction of experimental features like `clientSegmentCache`. This addresses a bug where conflicting routes while incremental PPR was enabled that matched routes incorrectly, for example: ``` /~/monitoring <- PPR disabled /[teamSlug]/monitoring <- PPR enabled ``` Would previously cause client segment requests for `/~/monitoring` to match `/[teamSlug]/monitoring`. This addresses it by adding early rewrites to handle this case. This will be removed in future versions when incremental PPR is deprecated. ### Enhancements to prefetch segment data routes: * Added a new utility, `buildInversePrefetchSegmentDataRoute`, to support inverted prefetch segment data routes, which rewrite from segment paths back to prefetch RSC routes. This is particularly useful for handling dynamic routes without conflicts when partial prerendering is disabled (`packages/next/src/server/lib/router-utils/build-prefetch-segment-data-route.ts`). * Updated the `PrefetchSegmentDataRoute` type to include `routeKeys` for better route matching and added logic for generating these keys (`packages/next/src/server/lib/router-utils/build-prefetch-segment-data-route.ts`). [[1]](diffhunk://#diff-35b900720f7fd8bc8995f5dad9880b2ffafba0638ec6c949efc9ba34b0acc9cbR15) [[2]](diffhunk://#diff-35b900720f7fd8bc8995f5dad9880b2ffafba0638ec6c949efc9ba34b0acc9cbL27-R29) * Modified the build process to utilize `buildInversePrefetchSegmentDataRoute` for dynamic routes with undefined segment paths when `clientSegmentCache` is enabled (`packages/next/src/build/index.ts`). ### Codebase improvements: * Added `originalAppPath` to the `PageInfo` interface to track the original path of app pages and routes, improving route handling logic (`packages/next/src/build/utils.ts`). * Simplified the logic for appending prefetch segment data routes by directly pushing the result of `buildPrefetchSegmentDataRoute` instead of using intermediate variables (`packages/next/src/build/index.ts`). ### Testing and experimental features: * Added comprehensive unit tests for `buildInversePrefetchSegmentDataRoute` to ensure correct behavior and compatibility with existing route utilities (`packages/next/src/server/lib/router-utils/build-prefetch-segment-data-route.test.ts`). * Introduced a new E2E test suite for validating conflicting routes and prefetching behavior under the experimental `clientSegmentCache` feature (`test/e2e/app-dir/segment-cache/conflicting-routes`). * Enabled experimental features like `clientSegmentCache` and `ppr` (partial prerendering) in the test configuration to validate their integration (`test/e2e/app-dir/segment-cache/conflicting-routes/next.config.js`).

### What? - Use `analyze.references()` beacuse we need imports to be in `esm_references`. ### Why? It's identical but cleaner. Closes PACK-4397

This auto-generated PR updates the production integration test manifest used when testing Turbopack.

…t test performance (#78388) ## Why? I'm trying to run https://github.com/boshen/cargo-shear over our workspace to remove unused dependencies. It runs `cargo expand` with `--all-features`, which was breaking on this crate. ## Changes Summary - Add `opt-level = 1` in dev for this crate. - Reduce the iterations used in tests. If we really want tons of iterations, we should use benchmarks or write a fuzzer utility. Unit tests should be small and fast. - Increase the test for blobs to use a 65KiB blob size and assert that's larger than the blob threshold. - Cleanup: Use the more-correct `u32` type for the `family` field in a few more places instead of `usize` and make the numeric representations of the `KeySpace` enum a bit more explicit. ## Prior to these changes - Building with `--features turbo-persistence/verify_sst_content` would fail with compilation errors - Unit tests would take multiple minutes to run - The blob test didn't appear to actually test blobs (10KiB < 64KiB) ## After these changes - The `verify_sst_content` feature works and passes unit tests - Unit tests finish in about a minute with `cargo test` and `cargo nextest`, this is still slow, but much better than it was. - Unit tests actually test blobs as intended. ![Screenshot 2025-04-21 at 2.12.32 PM.png](https://graphite-user-uploaded-assets-prod.s3.amazonaws.com/HAZVitxRNnZz8QMiPn4a/ff7aa104-c193-4514-9fde-1a6fcc11acf8.png) ## Potential future work It would be useful to be able to adjust the medium and large (blob) size thresholds to allow us to lower those thresholds in tests.

Rejoice! The day has come. Hopefully, we'll never see `AssertionError: Assertion failed: WebAssembly is uninitialized` ever again. I dug into amphtml-validator's code, and discovered that they have a race condition when initializing. This PR works around it. The root problem is that `AmpValidator.getInstance` is buggy when multiple calls to it occur in parallel. See, the point of `AmpValidator.getInstance(validatorPath)` is to re-use instances across multiple calls. It attempts to do that by stashing created instances in `instanceByValidatorJs`. However, when creating a fresh instance, it is added to `instanceByValidatorJs` **before `instance.init()` is finished**: https://github.com/ampproject/amphtml/blob/0c8eaba73ca8f5c462a642fa91901a29e6304f6e/validator/js/nodejs/index.js#L309-L313 which means that, if a concurrent call to `AmpValidator.getInstance(validatorPath)` happens before the original `instance.init()` is done, then we'll get back an uninitialized or partially initialized instance: https://github.com/ampproject/amphtml/blob/0c8eaba73ca8f5c462a642fa91901a29e6304f6e/validator/js/nodejs/index.js#L292-L294 And, since `instance.init()` is the part that handles loading the webassembly code, this race results in the dreaded `AssertionError: Assertion failed: WebAssembly is uninitialized` error when calling methods on the not-yet-initialized validator. As a workaround, we properly dedupe instance creation on our own. I'll submit a fix to the original repo as well, but this should solve the problem for us.

#78386) Incorporating availability info into the hash digests for asynchronous loaders resulted in many copies of loaders being created, each with identical content, as there were many routes in the graph to loading a chunk. This way, we deduplicate loaders while still creating unique loaders when truly needed. Test Plan: Tested in `cal.com`. Verified the number of output loaders for server chunks for `packages/app-store` went from 50 copies to one.

This removes the `--turbopack` and `--turbo` flags from `next start`, as it correctly launches the server to handle Turbopack builds without the flag. It also removes this section from the documentation. This is a breaking change, but Turbopack-powered builds are experimental, so this can probably go out with the next stable release.

The `turbo_tasks::emit` function (https://turbopack-rust-docs.vercel.sh/rustdoc/turbo_tasks/fn.emit.html) already requires a `ResolvedVc`, so all of these values should be a `ResolvedVc`. That makes things easier for code consuming collectibles. Collectibles need some documentation, but they're how we emit diagnostics or collect file writes that are accumulated at the top-level. They're effectively tracked side-effects for a function. Collectibles are deduplicated. We need somewhat sane equality definitions, so we use `ResolvedVc` for that (we want to eventually remove the `Eq` definition on `Vc`, it doesn't behave as one might expect).

…nges (#78211) ### What? Add a test case that checks if we can apply changes to the app after restoring from cache.

Starting from Node.js v14.17.0 and v15.6.0, we can use Node.js's `randomUUID` function in the crypto module to generate version 4 UUID. Since Next.js requires Node 18 or newer, we can replace `uuid` dependency with `crypto.randomUUID`. Reference: https://nodejs.org/docs/latest-v18.x/api/crypto.html#cryptorandomuuidoptions Signed-off-by: Eng Zer Jun <[email protected]> Co-authored-by: Jiwon Choi <[email protected]>

pull bot added the ⤵️ pull label Mar 1, 2025

huozhi and others added 29 commits April 4, 2025 16:44

Avoid microtaskiness when lazily fetching from cache handlers (#77843)

d6ccb2b

v15.3.0-canary.39

66514a6

v15.3.0-canary.40

2139369

Update Turbopack production test manifest (#77872)

fd5f588

This auto-generated PR updates the production integration test manifest used when testing Turbopack.

[test] consolidate missing tag dev test (#77896)

45e8a6f

This test is flaky in headless mode but passing in browser mode. It was timeout on checking the toast. Adding an assertion for it seems resolve the issue

v15.3.0-canary.41

8f1409d

fix: flaky test detection needs to use new turbopack flag (#77908)

ab2ebb1

As of #77894, there's a new way to indicate Turbopack should run, which breaks flaky tests detection with Turbopack. This swaps out the flag to unblock my downstack PR.

Update bundler development test manifest (#77884)

aa7d940

This auto-generated PR updates the development integration test manifest used when testing alternative bundlers.

Update bundler production test manifest (#77885)

4f85a28

This auto-generated PR updates the production integration test manifest used when testing alternative bundlers.

v15.3.0-canary.42

82ab39f

fix(next/image): bump [email protected] (#77839)

d6d219d

This PR updates deps to `[email protected]` to fix few bugs we found: - lovell/sharp#4277 - lovell/sharp#4328 See the full list of changes here: lovell/sharp#4248

Update Turbopack development test manifest (#77886)

777b826

This auto-generated PR updates the development integration test manifest used when testing Turbopack.

Update bundler production test manifest (#77914)

40c53e0

This auto-generated PR updates the production integration test manifest used when testing alternative bundlers.

Update bundler development test manifest (#77915)

e69918d

This auto-generated PR updates the development integration test manifest used when testing alternative bundlers.

huozhi and others added 30 commits April 18, 2025 01:50

Add graceful error boundary for bots requests (#78298)

527fe7a

v15.3.1-canary.14

0ecb7e4

v15.3.1-canary.15

21d2a32

v15.4.0-canary.0

8ed3b93

refactor(turbopack): Remove needless code (#78331)

a0696f2

### What? - Use `analyze.references()` beacuse we need imports to be in `esm_references`. ### Why? It's identical but cleaner. Closes PACK-4397

v15.4.0-canary.1

68e62be

Update Turbopack production test manifest (#78371)

b77356a

This auto-generated PR updates the production integration test manifest used when testing Turbopack.

v15.4.0-canary.2

b90d160

Turbopack: add random_change test case to test persistent caching cha…

28ab6c9

…nges (#78211) ### What? Add a test case that checks if we can apply changes to the app after restoring from cache.

Update Turbopack development test manifest (#78399)

74303f5

Upgrade React from 4a36d3ea-20250416 to bc6184dd-20250417 (#78322)

4be6924

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[pull] canary from vercel:canary #608

[pull] canary from vercel:canary #608

pull bot commented Mar 1, 2025 •

edited

Loading

[pull] canary from vercel:canary #608

Are you sure you want to change the base?

[pull] canary from vercel:canary #608

Conversation

pull bot commented Mar 1, 2025 • edited Loading

pull bot commented Mar 1, 2025 •

edited

Loading