KSP: Consistently failing build in first run and success on second run
ArcherEmiya05 opened this issue · 15 comments
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
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.
I am also experiencing this problem (just commenting to raise awareness of this one)
Thanks, if you can provide a project reproducing this that would help a lot.
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.
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.
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.
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.
@wanyingd1996 I just tried it out after the release of Dagger 2.51 and I am still seeing this problem unfortunately
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!
@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)
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.