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

Stale task outputs with configuration cache active

On Gradle 8.4 and later, enabling the configuration cache alongside the build cache appears to change which task input properties participate in the cache key. The documented behavior is that the configuration cache serializes the task graph once and reuses it, while the build cache keys task outputs on declared inputs. The uncertainty is what happens at the boundary: when a plugin upgrade or a task class hierarchy change alters the set of input properties, can a previously stored cache entry still be considered a hit because the serialized graph captured only a subset of inputs?

Constraints

The scenario is a multi-module build where some tasks produce side-effect-free transformations and their only detectable input changes come from the plugin classpath, not from file inputs. The --configure-on-demand-cache-key diagnostic flag mentioned around 8.4.2 is sparsely documented, and it is unclear whether it covers plugin-driven input changes or only configure-on-demand key computation. Verification would involve comparing checksums between a clean build and a cache-reused build and inspecting UP-TO-DATE and FROM-CACHE outcomes with --info.

Questions

• Which input properties are guaranteed to be part of the build cache key when the configuration cache is active, and does a plugin version change force key invalidation?
• Is --configure-on-demand-cache-key intended to diagnose this class of stale hit, and what output does it actually produce?
• Is there a supported way to make task cache keys include the task implementation classpath explicitly?