[pull] canary from vercel:canary#454
Merged
pull[bot] merged 6 commits intocode:canaryfrom Oct 13, 2025
Merged
Conversation
The peerDeps are already bumped to 19.2.0 at #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>
Closes #84734 Fixes environmental variable names in `with-supabase` example README to match the actual `.env.example` file. Updates `NEXT_PUBLIC_SUPABASE_ANON_KEY` to `NEXT_PUBLIC_SUPABASE_PUBLISHABLE_OR_ANON_KEY` in two locations. --------- Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
#84765) ### What? This makes sure to use the same method for serializing CachedTaskType for storing and lookup. Before that we instantiated the serialization twice and that caused some weird behavior on linux. Before this fix I was seeing that serialization of CachedTaskType was not byte to byte identical between storing and lookup. This caused tasks to not be found, which will lead to very weird effects: stale tasks, cell not found, etc. I was expecting that pot serialization is deterministic, but turns out it isn't fully deterministic. It has some logic to deduplicate Symbols (like enum variant names). But it deduplicates these `&'static str`s based on the pointer address of the static string. Turns out that Rust doesn't guarantee that static strings are deduplicated in all cases. I assume that we are somehow running into that problem when having two variants of the serialization. They ended up serializing task types differently (one didn't have a symbol deduplicated in the serialized form. But that's more a wild guess. It did fix the bug, but I have a hard time understanding why this is happening. On long term, I think we should change pot to avoid using pointer addresses and do a real comparision instead. > why does the `inline(never)` fix it? I'm not super sure, but here is my theory. The rust compiler on linux is very aggressive in inlining the whole stuff, up to the point where it inlines the Serialize implementation of CachedTaskType and RawVc into the call side (`turbo-tasks-backend` crate). It can't inline the Serialize implementation that's behind the `arg` `MagicAny` stuff. So we are duplicating the RawVc Serialize logic into two crates. This way we end up with two `&'static str` of `TaskCell` for the enum variant. This string is not deduplicated during linking for whatever reason (It's not guaranteed). So in the end the Symbol is not deduplicated in the serialized form of the CachedTaskType. The stuff above might happen or not. It's in the fate of the compiler. And we also don't rely on that the Symbol is deduplicated. But we rely on a deterministic serialized version. The problem is that the lookup path and the store path have two separate calls to `serialize`, so it might end up inlining into two different places. So that might end up being aggressive in one place and not so aggressive in the other place. So in the end it might end up deduplicating in the lookup path and not deduplicating in the store path, which would cause different serialized versions in the two paths. To avoid that, I changed to code to use the `serialize_task_type` function in both places. And the `inline(never)` ensures that it won't be duplicated by inlining. Don't ask me how long it took to figure that out...
### What? update petgraph to latest version
Same as #84701 except for DirAssets which are what we create for things like `path.resolve` or `path.join`
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.
5 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 : )