Turborepo misses cache to restore Next.js applications with Skew Protection enabled on Vercel

[ben-horner-crimson]

Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/vercel/turborepo/tree/main/examples/basic

Which canary version will you have in your reproduction?

turbo 2.5.4-canary.0

Environment information

CLI:
   Version: 2.5.4-canary.0
   Path to executable: **projects/crimson/cga-turbo-test/node_modules/turbo-darwin-arm64/bin/turbo
   Daemon status: Running
   Package manager: npm

Platform:
   Architecture: aarch64
   Operating system: macos
   WSL: false
   Available memory (MB): 3342
   Available CPU cores: 8

Environment:
   CI: None
   Terminal (TERM): xterm-256color
   Terminal program (TERM_PROGRAM): vscode
   Terminal program version (TERM_PROGRAM_VERSION): 1.100.1
   Shell (SHELL): /bin/zsh
   stdin: false

Expected behavior

Following the documentation here and here and following the video here using the example repo here linked to a project in vercel with these settings:

I expect to do the following:

• run turbo login
• run turbo link
• navigate to my package sub dir and run vercel login and vercel link
• create a project linked to the cloned repo in github
• run turbo build locally
• see my locally built cached artifacts in remote cache
• trigger a CI build in vercel, making no changes to build inputs or env
• see a cache hit in the CI build
• make a local change, push without build
• wait for vercel CI build to complete
• see CI built artifacts in remote cache
• run turbo build locally and see a cache hit from the remote cache

Actual behavior

I actually see the following:

• run turbo login
• run turbo link
• navigate to my package sub dir and run vercel login and vercel link
• create a project linked to the cloned repo in github
• run turbo build locally
• see my locally built cached artifacts in remote cache but classified as no-project
• trigger a CI build in vercel, making no changes to build inputs or env
• see a cache miss in the CI build
• make a local change, push without build
• wait for vercel CI build to complete
• see CI built artifacts in remote cache linked to project name
• run turbo build locally and see a cache miss from the remote cache

To Reproduce

• clone this repo
• create a project vercel, linked to the above repo with these settings:

- `turbo login` - `turbo link` - `cd apps/docs` - `vercel login` - `vercel link` - make a change and commit - `turbo build` - push your change to trigger a vercel CI build - check CI pipeline to verify miss or hit - make change locally - commit and push to trigger new build and cache remotely - `turbo build` locally - check locally for cache hit from remote cache

Additional context

No response

[chris-olszewski]

At the moment the way Next.js implements Skew Protection we are unable to restore any cached Next.js builds for deployments as they would break Skew Protection. We have a plan for fixing this, but we do not have a timeline.

See our documentation for more details: https://vercel.com/docs/monorepos/turborepo#limitations

[ben-horner-crimson]

I have managed to workaround this by using the following turbo config...although not sure if this introduces any undesirable side effects:

{
  "$schema": "https://turborepo.com/schema.json",
  "ui": "tui",
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["$TURBO_DEFAULT$", ".env*"],
      "outputs": [".next/**", "!.next/cache/**"],
      "env": ["!VERCEL_DEPLOYMENT_ID", "!VERCEL_TARGET_ENV"]
    },
    "lint": {
      "dependsOn": ["^lint"]
    },
    "check-types": {
      "dependsOn": ["^check-types"]
    },
    "dev": {
      "cache": false,
      "persistent": true
    }
  },
  "globalEnv": ["!VERCEL_DEPLOYMENT_ID", "!VERCEL_TARGET_ENV"]
}

[anthonyshew]

@ben-horner-crimson This does indeed introduce undesirable side-effects. It effectively "turns off" Skew Protection.

[paul-vd]

@anthonyshew any news on this? I suspect we can use @ben-horner-crimson solution untill there it is resolved, but imposes other risks...

From my understanding as long as skew protection is enabled turborepo is on deployments?

[martiinii]

I've just ran into this issue as well. Afaik Skew Protection is enabled only for pro accounts, but I have same issue on my hobby account - in run summary from Vercel I can see additional VERCEL_TARGET_ENV (missing when building locally with --dry=json) in inferred section which causes the hashes to be different.
Would ignoring this env in turbo config like @ben-horner-crimson would cause any issues for anyone on hobby account?

[controversial]

Does experimental.runtimeServerDeploymentId resolve the need for the deployment id to invalidate turborepo caches in nextjs apps?

if so, are there plans to remove the cache-busting deployment id from the framework-default envConditionals ?