KSP: Consistently failing build in first run and success on second run

[ArcherEmiya05]

Having same setup mentioned in this closed issue. We noticed that after migrating to KSP, we always get these errors on first run (after applying changes to codebase) then success when we run again the project.

Using AGP 8.2.0 in Android Hedgehog

[mackenzie-powers-mahana]

I'm also having this issue with an app using Circuit and its associated codegen artifacts; I'll try to create a simple project to reproduce the issue.

[palpapp04]

I am also experiencing this problem (just commenting to raise awareness of this one)

[bcorso]

Thanks, if you can provide a project reproducing this that would help a lot.

[palpapp04]

That might be tricky because to me it is happening with pretty large commercial app but I will try to reproduce this with a sample project over the weekend by isolating a module where the stack trace points to and deleting everything that's irrelevant (no promises though 😄). I also have a smaller project but that does not uses @ContributesAndroidInjector and there KSP works as expected so that's definitely needed to reproduce this bug.

[MaratTursynbek]

I'm also experiencing this. In addition to the author's description, despite second build being successful, it takes way longer to build and run than it was before. It feels like there is no incremental build and full clean rebuild is happening. Changing even one line of kotlin code makes it 5 minutes to run in the emulator. Before it would take me less than 10 sec to get latest code into the running app. XML code changes work fine - runs on 1st attempt and fast compilation times as before.

I also tried with AGP 8.2.1 and kotlin 1.9.22 with ksp 1.9.22-1.0.16 and the problem is still there.

[MasaHirano]

Dear @bcorso,

I am also facing this issue. In my case, the issue happens when I modify an Activity file that hosts fragments. I created a sample project where I can reproduce it on my end.
https://github.com/alpaca0984/DaggerKspIssueRepro

I hope it helps the investigation.

[wanyingd1996]

I tried patching the repro, and can consistently reproduce the issue with dagger 2.50. But the issue seems to be gone with dagger at head. So next release should fix this problem.

[palpapp04]

@wanyingd1996 I just tried it out after the release of Dagger 2.51 and I am still seeing this problem unfortunately

[wanyingd1996]

Hi, I was able to repro the problem at head, not sure why couldn't repro earlier. It seems to be a ksp bug where the cached generated source file wasn't discoverable by the processor. I'm working with ksp team on this issue now, will follow up once made progress. Thanks for the patience!

[palpapp04]

@wanyingd1996 Thank you for the fix on this issue. I just upgraded my project to the latest dagger version and for me the issue still persist however I am getting a different exception than before saying that a generated file already exists. I saw that there is a similar issue #4161 but in my project I do not use hilt and I still get this exception. After building again the issue disappears just like before. Here is my stack trace, I would appreciate if you would take a look and let me know if I should open a new issue for this one.

Thanks in advance.

java.nio.file.FileAlreadyExistsException: ~\build\generated\ksp\*******Debug\java\com\***\***\***\***\***\*******_Factory.java
	at java.base/sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:124)
	at java.base/sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:284)
	at java.base/java.nio.file.Files.copy(Files.java:1305)
	at com.google.devtools.ksp.common.IncrementalUtilKt.copyWithTimestamp(IncrementalUtil.kt:80)
	at com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension.updateFromShadow(KotlinSymbolProcessingExtension.kt:477)
	at com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension.doAnalysis(KotlinSymbolProcessingExtension.kt:375)
	at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration(TopDownAnalyzerFacadeForJVM.kt:112)
	at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration$default(TopDownAnalyzerFacadeForJVM.kt:77)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler$analyze$1.invoke(KotlinToJVMBytecodeCompiler.kt:256)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler$analyze$1.invoke(KotlinToJVMBytecodeCompiler.kt:247)
	at org.jetbrains.kotlin.cli.common.messages.AnalyzerWithCompilerReport.analyzeAndReport(AnalyzerWithCompilerReport.kt:115)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyze(KotlinToJVMBytecodeCompiler.kt:247)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.repeatAnalysisIfNeeded(KotlinToJVMBytecodeCompiler.kt:181)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.repeatAnalysisIfNeeded(KotlinToJVMBytecodeCompiler.kt:181)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli(KotlinToJVMBytecodeCompiler.kt:87)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli$default(KotlinToJVMBytecodeCompiler.kt:43)
	at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:165)
	at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:50)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:104)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:48)
	at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:101)
	at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1523)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
	at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
	at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
	at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:840)

[wanyingd1996]

Hi, @palpapp04, from the stack trace you provided, nothing points to dagger or hilt, it seems a bug from ksp side during incremental processing that fails to handle generated file. It is different from #4161, as that bug happens when hilt is trying to write file. So I think you may want to try bump your ksp version first, if it still fails, file a bug to the ksp issue.

[ivtoto]

I'm on Kotlin 2.0.0, KSP 2.0.0-1.0.24 (the same is reproducible with 2.0.20-RC and 2.0.20-RC-1.0.24), and Dagger 2.52, and I'm now having the same/similar issue:

• the first build passes just fine
• the second and following builds are failing with java.nio.file.FileAlreadyExistsException
• if I clean the build (gradle clean) - the first following build passes and then the same issue again with the next ones

The "duplicated class" is found in 3 places:

• /.../projectFolder/app/build/generated/ksp/buildVariant/java/com/...
• /.../projectFolder/app/build/generated/ksp/buildVariant/java/byRounds/1.com/...
• /.../projectFolder/app/build/generated/ksp/buildVariant/java/byRounds/2.com.project/...

Other details:

• Gradle 8.9
• AGP 8.5.1
• reproducible with all Dagger 2.51, 2.51.1, and 2.52

java.nio.file.FileAlreadyExistsException: /pathToProjectFolder/app/build/generated/ksp/buildVariant/java/com/**/**/**/**_MembersInjector.java
	at java.base/sun.nio.fs.UnixFileSystem.copy(Unknown Source)
	at java.base/sun.nio.fs.UnixFileSystemProvider.copy(Unknown Source)
	at java.base/java.nio.file.Files.copy(Unknown Source)
	at com.google.devtools.ksp.common.IncrementalUtilKt.copyWithTimestamp(IncrementalUtil.kt:80)
	at com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension.updateFromShadow(KotlinSymbolProcessingExtension.kt:477)
	at com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension.doAnalysis(KotlinSymbolProcessingExtension.kt:375)
	at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration(TopDownAnalyzerFacadeForJVM.kt:112)
	at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration$default(TopDownAnalyzerFacadeForJVM.kt:75)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyze$lambda$12(KotlinToJVMBytecodeCompiler.kt:373)
	at org.jetbrains.kotlin.cli.common.messages.AnalyzerWithCompilerReport.analyzeAndReport(AnalyzerWithCompilerReport.kt:112)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyze(KotlinToJVMBytecodeCompiler.kt:364)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.repeatAnalysisIfNeeded(KotlinToJVMBytecodeCompiler.kt:282)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.repeatAnalysisIfNeeded(KotlinToJVMBytecodeCompiler.kt:282)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.runFrontendAndGenerateIrUsingClassicFrontend(KotlinToJVMBytecodeCompiler.kt:195)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli(KotlinToJVMBytecodeCompiler.kt:106)
	at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:170)
	at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:43)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:103)
	at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:49)
	at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:101)
	at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1555)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
	at java.rmi/sun.rmi.transport.Transport$1.run(Unknown Source)
	at java.rmi/sun.rmi.transport.Transport$1.run(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at java.rmi/sun.rmi.transport.Transport.serviceCall(Unknown Source)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

[bcorso]

@ivtoto is the issue reproducible with KSP 1.9.24-1.0.20?

[ivtoto]

@bcorso Yes, I just tested it, and it's the same. Using: Kotlin 1.9.24, KSP 1.9.24-1.0.20, and Dagger 2.52.
I also tested with Dagger back to 2.49 - the same issue.
The first build passes and the following fail until a clean is performed.
The only "workaround" I found is to turn off the incremental build for KSP: ksp.incremental=false.

[bcorso]

@palpapp04 @ivtoto thanks this sounds like another bug in KSP. You can either file a bug with the KSP team (https://github.com/google/ksp/issues) or if you have a repro of the issue we can take a look and work with the KSP team to resolve it.

[alizarei95]

There is a similar issue on ksp
google/ksp#1678