Question
IntelliJ IDEA: Gradle build cache invalidation after dependency version update
Sora Nova
0 reputation · 17 Oct 2020, 22:29 UTC
95K views1
Loading…
0 reputation · 17 Oct 2020, 22:29 UTC
If IntelliJ IDEA appears to return stale build cache results after a dependency version change, the goal is to verify whether the cache is incorrectly reusing outdated outputs. The investigation should avoid clearing the entire cache or disabling the feature, focusing instead on inspecting cache keys, input timestamps, and task up‑to‑date checks. Uncertainty remains about which specific inputs affect cache validity for the changed library and how IntelliJ reports cache hits versus misses in the Build window.
Which cache key components should be examined to confirm that the new library version is part of the input set? How can the build log be interpreted to distinguish a true cache hit from a stale reuse?
34775 reputation · 18 Oct 2020, 06:21 UTC
To confirm the library version is part of the input set, examine the following components within the Gradle build environment:
gradle
intellijbuild.gradle or gradle.versions.toml changes, the hash for the compileClasspath configuration must change.@Input. If a task relies on a JAR file manually without tracking its version, Gradle may not detect the update.build/gradle-cache-metadata directory (or remote metadata) to see the fingerprints of the inputs used for the specific task execution.To distinguish a true cache hit from a stale reuse, run your build with the info flag and filter for task execution status:
./gradlew build --build-cache --info
Look for these specific indicators in the output:
FROM-CACHE: This indicates a valid build cache hit. If you see this after changing a version, Gradle believes the inputs are identical. Check for dynamic versions or constraints.UP-TO-DATE: This means the task was skipped because local inputs haven't changed. If this appears after a version update, the IDE may not have registered the change with Gradle.EXECUTED: This indicates the task ran normally. If this happens but the output is old, the task is not being invalidated, but the process itself is working.If the cache seems stale despite version changes, follow these steps to isolate the failure:
Tools > Gradle > Refresh Gradle Projects. This ensures the IDE's internal model matches the Gradle build script../gradlew --info to see the exact file paths and hashes Gradle is comparing. Compare these before and after the update../gradlew clean to ensure stale local classes aren't being picked up by the compiler manually.Are you using dynamic versioning (e.g., 1.+) or snapshot dependencies? This significantly alters how cache keys behave.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 18 Oct 2020, 05:55 UTC
One point worth adding to the cache-key discussion: the scenario that most often produces genuinely stale reuse isn't a fixed version bump (which reliably changes the resolution hash, as described above) but a dynamic or changing version — 1.+ or a -SNAPSHOT. Gradle caches the resolution of those for 24 hours by default, so after publishing a new snapshot you can see a legitimate FROM-CACHE result that is technically "correct" per the cache key yet semantically stale.
Two practical checks before touching any cache:
./gradlew dependencyInsight --dependency your-module --configuration runtimeClasspath to confirm which version Gradle actually resolved, rather than inferring it from ~/.gradle/caches/modules-2 (old artifacts linger there harmlessly).--refresh-dependencies once, or set cacheChangingModulesFor 0, 'seconds' / cacheDynamicVersionsFor in the build to tighten the TTL.Also keep the two caches separate in your diagnosis: Gradle's build cache vs. IntelliJ's own indexes. If the CLI build resolves correctly but the IDE still shows the old JAR in External Libraries, a Gradle sync (or Build > Rebuild Project) is the fix — Invalidate Caches should be the last resort, not the first. Exact menu names and TTL defaults vary by IDEA/Gradle version, so verify against yours.