Remote only does not work

[poacher2k]

Verify canary release

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

Link to code that reproduces this issue

Not code specific, just set --remote-only

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

npm

What operating system are you using?

Mac

Which canary version will you have in your reproduction?

2.0.4-canary.1

Describe the Bug

turbo run build --remote-only, or TURBO_REMOTE_ONLY=true turbo run build does not hit remote cache, and instead uses local cache.

Expected Behavior

It should only use remote cache and never local cache.

To Reproduce

turbo run build --remote-only, or TURBO_REMOTE_ONLY=true turbo run build

Additional context

As discussed with @anthonyshew in this Discord thread, copied below:

Discussion on Discord

[14:08] Daniel: Seems like this is something that shouldn't be possible, right? --remote-only and cache hit (outputs already on disk) ``` > dotenv -e .env.local -- cross-env NODE_ENV=production turbo run build --remote-only --filter=@my/service --summarize • Packages in scope: @my/service • Running build in 1 packages • Remote caching enabled ┌ @my/service#build > cache hit (outputs already on disk), replaying logs ``` [19:15] Anthony: It seems that that message is only notifying that the outputs are there, not necessarily that it restored it from local. If you delete the `.turbo/cache` directory from your project, do you still get a hit? [19:16] Anthony: Note: `.turbo/cache` is for ^2.0. If you're still on 1.x, it will be `./node_modules/.cache/turbo` that you'll delete. [21:13] Daniel: thanks for the reply! I guess it's not easy to tell the two cases apart then, but yes even after deleting `.turbo/cache` I get the same message [21:18] Daniel: furthermore, I'm running the remote cache server locally, and it's not being hit at all [21:19] Daniel: if I make a change and run the build again, though: ``` GET /v8/artifacts/ad7230cab43787c4 404 Not Found POST /v8/artifacts/events 200 OK ``` [21:19] Daniel: I've deleted everything I came across just to be sure [21:20] Daniel: `--remote-only` doesn't work, nor does `TURBO_REMOTE_ONLY=true` [22:42] Anthony: Interesting. I'm reproducing this - but I don't believe which touched this code for awhile. Could you open an issue on the repo so I don't forget about this? I'm in the middle of a few critical things already for today and don't want to lose this.

[NicholasLYang]

Thanks for the issue. I can't seem to repro this, is there any chance you could provide a minimum reproduction? Also, just to clarify, you're getting the "cache hit (outputs already on disk)" message, but do you get a cache hit from the local cache when the outputs are not on disk?

[poacher2k]

Thanks for the issue. I can't seem to repro this, is there any chance you could provide a minimum reproduction?

Sure, will look at this in the morning.

Also, just to clarify, you're getting the "cache hit (outputs already on disk)" message, but do you get a cache hit from the local cache when the outputs are not on disk?

On first build, the remote cache server gets hit with a 404 -> build happens -> it gets saved to remote cache. On all consequent builds the remote cache is never hit, and deleting both .turbo/cache and ./node_modules/.cache/turbo yields the same message saying "cache hit (outputs already on disk)".

[NicholasLYang]

Gotcha. Yeah this is all expected behavior. The first build flow is the expected situation for a cache miss: the request 404's, so there's no cache entry, and therefore we run. On the second build, we get a cache hit because Turborepo has an additional feature where the Turbo daemon watches your output directory and detects changes. If there are no changes for a given task hash, we don't even check the cache, since we know the outputs haven't changed at all. Tbh it's not even a cache hit, it's more like an explicit no-op. We could do a better job of explaining this behavior, both in docs and in our output (cc @anthonyshew), so we'll look into that.

If you wish to opt-out of the daemon behavior, you can pass the flag --no-daemon and that should get you a true remote only experience.

[poacher2k]

Thank you for explaining @NicholasLYang ! This makes sense then, and --no-daemon gives the expected results :)