A team's CI cache is keyed on the branch name to "make sure feature branches don't pollute main's cache." Builds are inconsistent — sometimes fast, sometimes a full reinstall, and occasionally a build succeeds locally but fails in CI with a dependency version mismatch. What's wrong with keying the cache that way?

A cache should be addressed by what it contains, not by when it ran or which branch built it — the correct key is a hash of the file that actually declares the dependencies (the lockfile), so the cache is reused exactly when the dependencies haven't changed and rebuilt exactly when they have, regardless of which branch is running. Keying on branch name instead means every branch either restores a stale cache built from an old lockfile (if one exists for that branch name) or gets no cache at all on its first run, and — worse — a branch whose cache was seeded when the lockfile was different can restore dependencies that don't match what's actually declared, which is precisely the kind of local-passes-CI-fails mismatch described. The fix is mechanical: derive the cache key from the lockfile's hash, the same way setup-java's cache: maven keys on pom.xml and setup-node's cache: npm keys on package-lock.json.