Skip to content

[Backport] Different fingerprints in the compile classpath for the same dependency #35184

@asodja

Description

@asodja

See issue: #32464. We should also backport a reproducer added with #34150.

It was fixed by using Kotlin snapshotter, but we could also fix it for 8.x by appending fallback zip hasher configuration to hasher if not null here:

@Override
public void appendConfigurationToHasher(Hasher hasher) {
hasher.putString(getClass().getName());
resourceHasher.appendConfigurationToHasher(hasher);
}

From: https://gradle.slack.com/archives/C0WTFHWT1/p1751885846837139?thread_ts=1750438715.527669&cid=C0WTFHWT1

Anže Sodja
Bisect shows that 5312efe is the first commit that fixes this.
This is from this PR: #26645

Anže Sodja
It looks to me that
ClasspathFingerprintingStrategy.compileClasspathFallbackToRuntimeClasspath
https://github.com/gradle/gradle/blob/cb0c615fb8e3690971bb7f89ad80f58943360624/pla[…]fingerprint/classpath/impl/ClasspathFingerprintingStrategy.java
could poison the cache with incorrect hash.

Anže Sodja
Yes, that seems to be the reason. The problem is that for ZipHasher we don't take into account fallback zip hasher when calculating configuration hash here:
https://github.com/gradle/gradle/blob/bc186c09d72c9cf0b93ea623c2ba0c5b8bf442a4/pla[…]va/org/gradle/api/internal/changedetection/state/ZipHasher.java
Luckily in Gradle 9 we don't use this fallback strategy so this is not an issue anymore

Basically if there was an library in build classpath and project used Kotlin scripts, build script classpath snapshotting could poison the fingerprinting cache. That cache is also reused for Java compilation snapshotting and that is why there is a bug.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions