[pull] canary from vercel:canary - #1349
Merged
Merged
Conversation
Follow-up to #97256, pairing with [vercel/vercel-packages#107](vercel/vercel-packages#107). The token exchange endpoint no longer returns a client-upload token derived from a store read-write token; it presigns the upload URL with the deployment's own Vercel OIDC identity and returns the URL, pinning the pathname, expiry, size cap, and access and overwrite policy server-side. No store credential exists anywhere after this lands, and no Blob SDK is needed here for the new path — the script PUTs the tarball bytes to the URL directly. The client only uses presigned-URL. The server still supports client tokens until we landed this and synced the mirror. Co-authored-by: Claude Code (kimi-k3[1m]) <noreply@anthropic.com>
The `issue_stale` workflow ran `actions/stale` once a day to mark issues with no activity in 545 days (~1.5 years) as stale and close them a week later, and to auto-close issues labeled `please add a complete reproduction` (2 days), `please simplify reproduction` (14 days), or `please verify canary` (14 days). Marking and closing issues based on inactivity is no longer wanted, so the workflow is deleted. The `STALE_TOKEN` secret has already been revoked. Co-authored-by: Claude Code (kimi-k3[1m]) <noreply@anthropic.com>
This PR is strictly a refactor, no logic should change. The idea is that we eventually want to run the image optimizer transform step in a child process. This PR refactors the code to make a new `transform.ts` that is lightweight and should reduce some of the overhead of loading a large module graph when spawning a new process.
…7749) The `issue_wrong_template.yml` workflow closed issues labeled `please use the correct issue template`. That label was only ever applied manually by maintainers and has not been used since January 2025 (9 issues total, ever), so every recent run of the workflow was skipped. This change removes the workflow along with its backing `wrong-issue-template` action (source, checked-in ncc bundle, and build script). Co-authored-by: Claude Code (kimi-k3[1m]) <noreply@anthropic.com>
## Summary Re-enable the `sync-io-blocks-root` production suite now that #97900 waits for child stdio to close before capturing build CLI output. This reverts the temporary skip from #97986 so CI flake detection exercises the route-specific sync I/O diagnostics again. ## Verification - `HEADLESS=true IS_WEBPACK_TEST=1 pnpm test-start-webpack test/production/app-dir/sync-io-blocks-root/sync-io-blocks-root.test.ts` <!-- NEXT_JS_LLM -->
Code freezes are now managed by toggling the existing `code freeze` repository ruleset in the repository settings, so the `code_freeze` workflow is no longer needed. It was also broken beyond repair: it targeted the legacy branch-protection API with a `CODE_FREEZE_TOKEN` secret that no longer exists instead of the rulesets the repository uses now, and it referenced a `releaseType` input that was never declared. This PR deletes the workflow and `scripts/code-freeze.js`, which had no other consumer. Note on the investigated alternative: resurrecting the workflow on top of the rulesets API with just `GITHUB_TOKEN` is not possible. Creating or updating repository rulesets requires the "Administration" repository permission, which the workflow token cannot be granted (`permissions: administration: write` is rejected as an invalid workflow, and even `write-all` gets `403 Resource not accessible by integration`). Verified empirically in https://github.com/eps1lon/github-actions-repository-dispatch-admin-permissions. Co-authored-by: Claude Code (kimi-k3[1m]) <noreply@anthropic.com>
Caveats: - I had to skip `react[-dom][/*]` and `private-next-rsc-server-reference` and `private-next-rsc-cache-wrapper` imports in the code hash and env-var tracking. Because those all end up pulling in app-page-turbo.runtime.prod.js which reads many env vars and would cause constant deopting. But this should still be correct. The code of these imports is included via the Next.js version, and no env vars should change the semantics of any of those imports. - Static env var reads are collected, but too dynamic accesses are silently ignored and don't lead to deopts (same goes for env var reads in native NAPI addons). This means that this cache reuse is not guaranteed to be 100% guaranteed to never lead to stale caches. - Code hashing and env var collection happens on a per-module basis. So if you put all use-cache functions into a single file and/or together with react components, then you will see extraneous invalidations. This will be fixed by either generally enabling module splitting for all of Turbopack, or by adding a special transform that does it for use-cache functions. Followups: - There are some env var static analysis gaps that will be immediate followups before broader testing. These are the various TODOs added in #95310 - Client components invalidation is very coarse grained right now (statically imports any client component anywhere -> deopt completely). Followup for the future. But the current setup is correct. This would just improve effectiveness further - Do this in dev as well. Currently there is no NFT at all in dev (for performance reasons) - Module splitting for more granular tracking - Include entropy when serializing server reference arguments for cache key Todo: - [x] Use implementation code hash (includes inlined env vars): from #94234 - [x] Include non-inlined runtime env vars: from #95310 - [x] Include client reference manifest (very coarse for now) - [x] Include Next.js version (for wire format, etc) - [x] This is now done for all use-cache entries now. Not just for `use cache: remote`. Is that the intended behavior? Yes - [ ] ~~if `NEXT_DEPLOYMENT_ID` is in the env vars. just deopt and don't care about stringifing and hashing the env vars~~ - [x] Is cache key size a problem? Currently you can get this: (values are always hashed) `CustomCacheHandler::get ["80e6f6560092f0078775e7e787c1c10ecf6dea0bc4",[],["d984fbaa996274737f3b59345a300a20","16.4.0-canary.5","__NEXT_NO_MIDDLEWARE_URL_NORMALIZE=undefined","NEXT_OTEL_PERFORMANCE_PREFIX=undefined","__NEXT_PRIVATE_ORIGIN=a04f4b9d6a8f42724740a480e9a2bc67c053dc04377be831c0e2c407a1422004","NEXT_PRIVATE_RESPONSE_CACHE_TTL=undefined","NEXT_PRIVATE_RESPONSE_CACHE_MAX_SIZE=undefined","__NEXT_CACHE_COMPONENTS=b5bea41b6c623f7c09f1bf24dcae58ebab3c0cdd90ad966bc43a45b44867e12b","__NEXT_ROUTER_BASEPATH=undefined","__NEXT_MANUAL_CLIENT_BASE_PATH=undefined","__NEXT_INSTRUMENTATION_CLIENT_ROUTER_TRANSITION_EVENTS=undefined","__NEXT_APP_NAV_FAIL_HANDLING=undefined","__NEXT_GESTURE_TRANSITION=undefined","__NEXT_USE_OFFLINE=undefined","NEXT_DEBUG_BUILD=undefined","__NEXT_VERBOSE_LOGGING=undefined...]] [["_N_T_/layout","_N_T_/page","_N_T_/","_N_T_/index"]]`
Refactor to unify the multiple places where this computation was happening
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.
4 participants
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 : )