Writing to cache fails with "provided value is too long when setting link name for"

[FredrikAugust]

Verify canary release

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

Link to code that reproduces this issue

https://github.com/FredrikAugust/sveltekit-vercel-adapter-turborepo-cache-bug

What package manager are you using / does the bug impact?

pnpm

What operating system are you using?

Mac

Which canary version will you have in your reproduction?

1.11.2

Describe the Bug

When using Turborepos Remote Cache functionality with SvelteKit and the SvelteKit Vercel adapter, the cache is never uploaded to the remote cache as it fails with a warning:

 WARNING  IO error: provided value is too long when setting link name for 

Attaching an image as well as it looks quite unique:

There isn't a lot of information online about this warning, and the only google result I get for the warning message is this mailing thread. The reply reads:

[...] use the E flag for tar, as file names are limited to 100 chars.

This put me on the track of file names being a problem for Turborepo when they exceed 100 characters.[0]

(I'm going to be speaking in context of the repro repository)

So I checked out the two folders we upload to the cache:

• .svelte-kit
• .vercel

The .svelte-kit folder doesn't contain any files with paths over 100, but the .vercel one does.

.vercel/output/functions/fn.func/node_modules/.pnpm/@sveltejs+kit@2.0.2_@sveltejs+vite-plugin-svelte@3.0.1_svelte@4.2.8_vite@5.0.10/node_modules/@sveltejs/kit/src/exports/node/polyfills.js

I suspect the extra long dependency paths are from pnpm.

By removing the Vercel adapter it works as expected.

Expected Behavior

It should allow file paths of preferably an arbitrary length, but at least long enough to support the example and then some:)

To Reproduce

The moving parts that make this reproducible:

• pnpm
• SvelteKit (with Vite)
• SvelteKit Vercel Adapter
• Turborepo

---

Clone the repro repository: https://github.com/FredrikAugust/sveltekit-vercel-adapter-turborepo-cache-bug

pnpm i
pnpm dlx turbo run build

You should see the following log messages at the bottom

>   ...Finishing writing to cache...                                                                                                                                                                                                                                                WARNING  IO error: provided value is too long when setting link name for 

Additional context

It appears that someone else had a similar problem here which was fixed in this PR: https://github.com/ostreedev/ostree-rs-ext/pull/165/files.

And from the Rust repository: https://github.com/rust-lang/rust/pull/109577/files

_TURBO-1950

[FredrikAugust]

@NicholasLYang Do you have a rough estimate for this? We're trying to decide if we should do anything about this on our end if it's a long-lived issue. If there's anything else I can do to assist I'd be more than happy!

[andreyluchianic]

same here turbo, pnpm, Vercel Adapter

:

 Tasks:    1 successful, 1 total
Cached:    0 cached, 1 total
  Time:    8.606s 

    ...Finishing writing to cache...                                                                                                                                                                                  WARNING  IO error: provided value is too long when setting link name for 

[laurens-mesure]

I'm running into the same issue. I'm using Next.js and pure node projects. I cannot get turbo to log the failing resource with turbo build 2&> error.log.

This is the output:

 WARNING  Failed to check if we can skip restoring outputs for auth#build: GrpcFailure(DeadlineExceeded). Proceeding to check cache
 WARNING  Failed to check if we can skip restoring outputs for auth#build: GrpcFailure(DeadlineExceeded). Proceeding to check cache
 WARNING  IO error: provided value is too long when setting link name for 
 WARNING  IO error: provided value is too long when setting link name for 

[git-no]

I am running into the same error with latest SvelteKit, Turbo, PNPM and Node 18, Vercel Adapter.

[mcmxcdev]

Also encountering this it seems, but difficult to debug. It looks like the build succeeded but then it dies.

I don't think it has to do with remote cache, because I disabled it temporarily and it still fails.

These are the logs from a first time setup of Turborepo on a Sveltekit project:

...more logs...

@smlxl/storage-explorer:build:     ~/_app/immutable/nodes/9.Jdqgm3i7.js.map
@smlxl/storage-explorer:build: [sentry-vite-plugin] Info: Successfully uploaded source maps.
@smlxl/storage-explorer:build: [sentry-vite-plugin] Info: Successfully finalized release.
  Tasks:    1 successful, 1 total
 Cached:    0 cached, 1 total
   Time:    35.038s 
Summary:    /vercel/path0/.turbo/runs/2aEQg24TRk0BWaoFiROR7ZvsFN7.json
 WARNING  IO error: provided value is too long when setting link name for 
Error: No Output Directory named "public" found after the Build completed. You can configure the Output Directory in your Project Settings.
Learn More: https://vercel.link/missing-public-directory

[lostintheway]

will this work on npm?

[FredrikAugust]

will this work on npm?

We used to use npm and it worked there. I think it's due to the longer names of pnpm dependency folders.

[isaacharrisholt]

Likewise. We didn't have this issue on Turbo versions pre-1.11, I believe. It was definitely introduced recently

[olafurns7]

This regression occurs when going from 1.10.14 to 1.11.2, most likely then the 10->11 move.

[chris-olszewski]

Hi all, sorry for the hold up. I believe https://github.com/vercel/turbo/pull/6838 fixes the issue, but it hasn't made it into a release yet. We're planning on cutting a canary today and if everything looks good we'll cut a patch with the fix tomorrow.

[chris-olszewski]

I've verified that 1.11.3-canary.2 doesn't run into the issue with symlinks on the provided reproductions. Running a patch release for 1.11.3 now.

Closing as I believe this is addressed, if you encounter the same/similar issue after 1.11.3 please open a new issue.

[dmitrc]

@chris-olszewski, I am still seeing the IO error: provided value is too long when setting link name issue when building Next.js 14 app in standalone mode with PNPM on Windows. Is the link name max length something that can be adjusted on the user side, or can the team investigate it further?

[bonitao]

Same here, also using PNPM on Windows. Repro:

pnpm dlx create-turbo@latest -e with-vue-nuxt -m pnpm longlink
cd longlink
pnpm build  # works fine
pnpm build  # works fine, yields FULL TURBO as expected
cd apps/docs
pnpm add @nuxt/image

Now enable the nuxt/image module.

diff --git a/apps/docs/nuxt.config.ts b/apps/docs/nuxt.config.ts
index bf4ba7c..b37af13 100644
--- a/apps/docs/nuxt.config.ts
+++ b/apps/docs/nuxt.config.ts
@@ -1,4 +1,7 @@
 // https://nuxt.com/docs/api/configuration/nuxt-config
 export default defineNuxtConfig({
   devtools: { enabled: true },
-});
+  modules: [
+    '@nuxt/image'
+  ]
+})

Then the cache never gets reused again, despite the input having the same hashes.

pnpm build  # results in a full build
pnpm build  # results in a full build again
rm -r apps/docs/.output
pnpm build  # now I get a FULL TURBO

Only sometimes I get the error:

WARNING IO error: provided value is too long when setting link name for apps/docs/.output/server/node_modules/css-tree

[bmelonis]

The error message went away but some large paths don't get cached with Next 13 and pnpm on Linux.

[joshnuss]

Not sure if this is related, by using Sentry with Turborepo causes random errors.

When I look thru the Turborepo Run Summary in Vercel's dashboard, it shows cache changing.

The log is suspiciously cut off at exactly 100 characters

I'm not totally sure if it's related, maybe one of the maintainers of turborepo can verify?

Screenshot


Link to issue on sentry-javascript: https://github.com/getsentry/sentry-javascript/issues/10429

[bouvb]

we got the same problem with multiple next 14 apps in standalone mode (tried with turbo 1.10.12 and then 1.13.0, but same result) we used pnpm on windows too and got this message :

WARNING IO error: provided value is too long when setting link name for '...module in the node module of standalone directory'

for example, the module was mime-db but every modules after the letter m weren't even there and after the next build, Next wasn't able to be found to be run (next build didn't work)

we used WSL after and it's seems to work on a linux env, we don't have this message anymore

[mlnima]

same here, running 4 of the same headless CMS project on a single server with NVMe SSD, building all at the same time is not friendly with server resources, I run them one after another but writing to cache takes too long,

[iki]

@chris-olszewski same here with turbo 2.0.11, pnpm 9.6.0, windows ... please reopen

Workaround:

{
      ...
      "outputs": [
        ".next/**",
        "!.next/cache/**",
        "!.next/standalone/node_modules" // Rebuild on package.json change anyway. Fails with https://github.com/vercel/next.js/issues/40760
      ]
}

^ @dmitrc @bonitao @bouvb @mlnima

WARNING  IO error: provided value is too long when setting link name for app/.next/standalone/node_modules/.pnpm/terser@5.31.3/node_modules/@jridgewell/source-map

[iki]

Workaround: <monorepo-root>/.npmrc:

; Do NOT set environment/host specific setttings (like registry or script-shell) here. Use ~/.npmrc

; Use hoisted packages for Next.js standalone build https://pnpm.io/npmrc#node-linker
; - Solves missing Next.js standalone build dependencies https://github.com/vercel/next.js/issues/48017
; - Solves Next.js standalone build breaking pnpm monorepo dependencies https://github.com/vercel/next.js/issues/65636
; - Solves Turborepo error writing to cache https://github.com/vercel/turbo/issues/6823
node-linker=hoisted

Also solves https://github.com/vercel/next.js/issues/48017 and https://github.com/vercel/next.js/issues/65636

Alternatively, if you only need to get rid of this caching error, you can skip it in turbo.json build task outputs:

{
      ...
      "outputs": [
        ".next/**", 
        "!.next/cache/**",
        "!.next/standalone/node_modules" // Rebuilds on package.json change anyway. Fails with https://github.com/vercel/next.js/issues/40760
      ]
      ...
}

@dmitrc @bonitao @bouvb @mlnima