Incremental compilation fails with "Number of loaded files in snapshots differs"

[graemerocher]

We are building support for KSP in Micronaut (a popular Java/Kotlin framework). The initial implementation is done but it fails with KSP incremental compilation enabled with an error "Number of loaded files in snapshots differs" on the second compile:

./gradlew test
> Task :kspKotlin FAILED

FAILURE: Build completed with 2 failures.

1: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':kspKotlin'.
> Number of loaded files in snapshots differs. Reported changed files: []

To reproduce download this example project and run ./gradlew cTK twice.

ksp-test2.zip

[SimonMarquis]

👋 This issue popped up again since 1.8.20-Beta-1.0.9.

Here is an example with 1.8.20-RC-1.0.9 on the android/nowinandroid project:
https://github.com/SimonMarquis/nowinandroid/actions/runs/4409825508/jobs/7726595603#step:9:1881

Should we create a new issue?

[neetopia]

@SimonMarquis I can't reproduce the bug consistently with a locally checked out repository, can you verify on your side with a snapshot build 1.8.20-RC-1.0.10-SNAPSHOT from repository https://oss.sonatype.org/content/repositories/snapshots/?

[neetopia]

for context, the snapshot contains fix from #1350 which I anticipate to fix

[SimonMarquis]

Sorry for not being able to test this, I did not found enough time to test it yet.
Though it still happens on Kotlin 1.8.20 and KSP 1.8.20-1.0.10.
https://github.com/SimonMarquis/nowinandroid/actions/runs/4600305482/jobs/8126733329#step:9:2079

It might very well be an issue with the non-statble (non-compatible?) Compose compiler 1.4.4-dev-k1.8.20-RC-88d9f3a8232.

[ZacSweers]

@neetopia did #1350 make it into 1.8.20-1.0.10? I'm still reproducing this in that release now in slackhq/circuit#454.

100% reproducible with the below steps

1. run ./gradlew check
2. make a small change to a source test file, such as adding a println in PetListSnapshotTest.kt
3. run ./gradlew check again
4. 💥

[neetopia]

yes #1350 was included in the release, but does not seem to fix the issue.

[neetopia]

I was able to reproduce @ZacSweers 's repro, but after I deleted both $HOME/.gradle/caches and project's .gradle/configuration-cache, and tries to do the reproduce steps again, it seems not reproducing anymore..

[Enaium]

I also encountered this problem when using 1.8.20-1.0.10, Need to run gradle clean before run the project each time

[neetopia]

@Enaium can you give me a reproduce project? I am not able to reproduce @ZacSweers 's sample anymore after manually removing home caches and project configuration caches. Right now I am not sure if that has anything to do with remote cache.

[ZacSweers]

I'm able to reproduce it 100%. Maybe try building once with 1.8.10 and then 1.8.20?

[neetopia]

7168  gco main
 7169  less gradle.properties
 7170  less gradle/libs.versions.toml
 7171  ./gradlew check
 7172  git log
 7173  gco z/kotlin1820
 7174  ./gradlew check
 7175  vi samples/star/src/test/kotlin/com/slack/circuit/star/petlist/PetListSnapshotTest.kt
 7176  ./gradlew check

yeah that was what I did try to reproduce. I was able to reproduce 100% as well before deleting both local caches. I have another laptop not with me that can still reproduce 100% as I did not try removing caches on that laptop.

[Enaium]

@Enaium can you give me a reproduce project? I am not able to reproduce @ZacSweers 's sample anymore after manually removing home caches and project configuration caches. Right now I am not sure if that has anything to do with remote cache.

https://github.com/Enaium/jimmer-sql-kt-vertx
But the project is using 1.8.10-1.0.9 now

[svenjacobs]

I'm facing the same issue since upgrading to Kotlin 1.8.20 and KSP 1.8.20-1.0.10. Interestingly I cannot reproduce this on my local machine but 100% in a GitHub Actions workflow, although the workspace is absolutely clean with no caches (I disabled the cache action to ensure this).

[G00fY2]

Same issue here. We run our Jenkins CI builds without any caching in place, so 100% clean build each time. After updating to Kotlin 1.8.20, KSP 1.8.20-1.0.10 and Compose compiler 1.4.5 we also see this build error.

[neetopia]

Hi all, thanks for the reports, I've pushed a fix in #1363 and it is now available as 1.8.20-1.0.11-SNAPSHOT in snapshot repository, you can add

  maven {
    url = uri("https://oss.sonatype.org/content/repositories/snapshots")
  }

in your project and try out this snapshot to see if it resolves your issue, if everything looks good I will do a hot fix release soon to address this issue.

[jeffdcamp]

So glad I found this issue.... we couldn't run after updating to Kotlin 1.8.20, KSP 1.8.20-1.0.10 and Compose compiler 1.4.5.

We just tried the 1.8.20-1.0.11-SNAPSHOT and all is working for us! (hope 1.8.20-1.0.11 releases soon :) )

[hansenji]

This fixed it for me as well in my CI/CD running Unit Tests

[masztalski]

Seems to work for me also. Waiting for final build

[neetopia]

Cool, hot-fix release should be available on Monday.

[svenjacobs]

I can also confirm that 1.8.20-1.0.11-SNAPSHOT fixes the problem 🎉 Thank you!

[lihenggui]

Cool, wait for the hot fix!

[neetopia]

hot fix is released as 1.8.20-1.0.11, closing this issue.

[rschattauer]

@neetopia I am still facing this issue with 1.8.22-1.0.11

[neetopia]

@rschattauer Can you please give me a reproduce repo for this issue in 1.8.22-1.0.11? Thanks.

[rschattauer]

@neetopia it's kind of rough, as locally I have 0 issues, while our CI (jenkins) throws 100% of the time on the branch where I update that

[pengdev]

Hey @neetopia I'm facing the same issue with 1.7.20-1.0.8 release, as we can not bump kotlin version in our project, is it possible to port the fix to the 1.7.20 kotlin release? Or could you suggest any workarounds that we can apply to our project to bypass this issue? Thanks in advance!

[neetopia]

We can't do a back port release, would disable incremental to mitigate this issue work for you?

[pengdev]

@neetopia Thanks for the suggestion, I did try to disable incremental and it did help mitigate this issue. I think we are ok with the workaround for now 👍