IntelliJ IDEA: Gradle build cache invalidation after dependency version update

Question

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?

Tasadduq Burney · Answer

To verify if IntelliJ IDEA is returning stale results after a dependency version change, you must distinguish between Gradle's build cache logic and IntelliJ's internal project indexing. When a version changes, Gradle generates a new cache key for the configuration; if the build is still using old code, the issue usually lies in how the inputs are tracked or how the IDE is failing to sync with the Gradle model.

Identifying Cache Key Components
To confirm the library version is part of the input set, examine the following components within the Gradle build environment:

Configuration Resolution Hash: Gradle hashes the entire dependency graph. If the version in build.gradle or gradle.versions.toml changes, the hash for the compileClasspath configuration must change.
  Task Inputs: For custom tasks, verify that the dependency version is declared as an @Input. If a task relies on a JAR file manually without tracking its version, Gradle may not detect the update.
  Artifact Fingerprints: Check the build/gradle-cache-metadata directory (or remote metadata) to see the fingerprints of the inputs used for the specific task execution.

Interpreting the Build Log
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.

Verification Steps
If the cache seems stale despite version changes, follow these steps to isolate the failure:

Force a Sync: In IntelliJ, go to Tools > Gradle > Refresh Gradle Projects. This ensures the IDE's internal model matches the Gradle build script.
  Inspect Task Inputs: Use ./gradlew  --info to see the exact file paths and hashes Gradle is comparing. Compare these before and after the update.
  Clean Local Artifacts: Run ./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.

IntelliJ IDEA: Gradle build cache invalidation after dependency version update

1 answer

Identifying Cache Key Components

Interpreting the Build Log

Verification Steps

Your perspective belongs here.

1 question comment