Gradle 8.4+ build cache returns stale outputs when configuration cache is enabled

Confirmed facts

When the configuration cache is enabled, Gradle still computes the build‑cache key from three independent sources:

1. The task’s declared input properties (those annotated with @Input, @InputFile, @InputDirectory, etc.).
2. The task’s implementation classpath – the JARs and directories that contain the task class and its dependencies.
3. The fully‑qualified task class name.

These components are combined into a hash that is stored alongside the cached output. The configuration cache only serializes the task graph for reuse; it does **not** alter how the build‑cache key is formed.

What a plugin version change does

If a plugin upgrade changes the implementation classpath of a task (e.g., a new version of the plugin JAR is added or removed), the classpath component of the key changes. Consequently the build‑cache key changes and the previously cached output is treated as a miss, even though the configuration cache may have reused the same task graph.

About --configure-on-demand-cache-key

This flag prints the **configuration cache key** for each project. It does **not** display the build‑cache key, so it cannot directly reveal a stale‑output hit caused by missing input properties. However, you can run a build with the flag before and after a plugin version change; the printed keys will stay the same while the build‑cache key (and thus the task execution) changes.

Making the implementation classpath explicit (if desired)

Gradle already includes the task implementation classpath in the build‑cache key by default. To make the dependency explicit in your task definition you can:

• Annotate a property with @Classpath (or @Input combined with @Classpath) so that its value participates in the key.
• Alternatively, use @PathSensitivity(PathSensitivity.RELATIVE) on a @InputDirectory that points to the plugin’s classpath directory.

These annotations are optional; omitting them does not exclude the classpath from the key.

Verification steps for your multi‑module build

1. Run a clean build with configuration cache enabled and capture the output:

./gradlew clean build --configuration-cache --info

2. Note which tasks show FROM-CACHE versus UP-TO-DATE.
3. Change a plugin version (e.g., update its dependency in the classpath configuration) and repeat the same command.
4. Observe that tasks whose implementation classpath changed now execute again (no FROM-CACHE), confirming that the build‑cache key changed.
5. Optionally add --configure-on-demand-cache-key to see that the configuration cache keys remain unchanged across the plugin version change.