Say a teammate edits a JSON schema that a Rust crate pulls in with include_str!. They build, the build is green, and the binary they get is the old one. Nothing is broken in the cache. It did exactly what it was told, and what it was told was incomplete.
That story is most of what you need to know about turbo's remote cache with Cargo, Go and uv. The rest is a few rules that don't depend on which version you run. Cargo, Go and uv support is still experimental, so defaults will move. These rules won't.
What an entry is
The hash comes from a fixed list: the task's input files, the hashes of the tasks it depends on, external dependencies, environment variables, arguments, the declared outputs, and a few more. For native toolchains, external dependencies include the identity of the toolchain, such as the compiler version, which turbo gets by running the tool.
Nowhere on that path does turbo check that the hash was complete. It can't, because it doesn't know what the tool read.
Remote trouble is cheap for the same reason. A 403 on read turns off remote reads and uploads for the run, and a 403 on upload turns off only uploads. After a few consecutive failures a short circuit breaker pauses remote traffic and tries again later.
What a native build has to promise
Turbo derives most of a native key itself. For Cargo that is the crate and its local dependency sources, the Cargo.lock closure and the full rustc -vV. For Go it is go.mod, go.sum, go version, and variables that change the build, like GOOS, GOFLAGS and CGO_ENABLED. For uv it is the uv.lock closure plus the identity of the uv binary and the interpreter. What turbo can't derive, you declare: env vars a build script reads go in env, files from outside the package go in inputs.
Too little in the key gives you a stale hit, a wrong result served with confidence. Too much gives you a needless miss, which is only slow. So the native defaults lean toward missing.
Outputs should be the thing you ship, not the tool's working state.
For Cargo, turbo resolves paths for the common layouts: the profile, a supported --target, a target directory inside the repo. It doesn't guess at anything else.
Nothing machine-specific should leak into the key or the bytes. A checkout path in the key means two clones never share an entry, and a build directory baked into a binary makes the entry differ by who produced it. That is why Go's GOCACHE and GOMODCACHE are left out of the key, and why -trimpath and -buildvcs=false matter to anyone who cares about identical bytes. Any extra argument on go build turns off automatic output caching, so set those flags through GOFLAGS, which is hashed.
Turbo doesn't sandbox the tool, so it trusts your declarations. Where it can't prove the key is complete, it declines to cache. Cargo library builds run uncached by default. So do Go modules without a single main, and uv builds whose backend isn't uv_build, because uv resolves those build dependencies outside uv.lock. Running every time is the honest answer when the alternative is a guess.
Two bugs in the restore path
Both were in how a local hit is restored, and both are fixed. The key and the archived bytes were fine. The layer in between was not.
Neither produced a wrong build for long, but "a hit" is a claim about the disk as well as the hash. Whatever makes a hit fast is part of what has to be right.
Why a shared cache makes a stale hit worse
A stale entry in a local cache misleads one person, who reruns with --force. In a remote cache, everyone who computes the same hash gets the same entry.
Back to the schema file. It sits outside the crate, so the default key doesn't contain it, and a signature proves the bytes weren't changed on the way, not that the key was complete. Declare the missing input and the hash changes, which orphans the bad entry instead of overwriting it. Until then, --force re-runs the task and overwrites the entry.