`NullPointerException` during KSP processing of MappedSuperclass in library dependency

[kylequera]

Important Notice

Thank you for opening an issue! Please note that, as outlined in the README, I currently only work on feature requests or bug fixes when sponsored. Balancing this project with professional and personal priorities means I have a very limited amount of effort I can divert to this project.

You must put in the work to address this issue, or it won't be addressed.

• I am willing to put in the work and submit a PR to resolve this issue.

Describe the bug
NullPointerException during KSP processing.

Kotlin: 2.1.0
Spring Data JPA: 3.4.x
OpenFeign Querydsl: 6.10.1
KSP: com.google.devtools.ksp:ksp:2.1.0-1.0.29

When abstract class BaseEntity is annotated with @MapperSuperclass and @QuerySupertype AND BaseEntity is in a separate library, KSP processing throws an NPE in the "client" project (the project that has a dependency on the separate library) inside of the OpenFeign querydsl library with stacktrace:

Execution failed for task ':kspKotlin'.
> A failure occurred while executing com.google.devtools.ksp.gradle.KspAAWorkerAction
   > java.lang.NullPointerException (no error message)

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':kspKotlin'.
    ...
Caused by: org.gradle.workers.internal.DefaultWorkerExecutor$WorkExecutionException: A failure occurred while executing com.google.devtools.ksp.gradle.KspAAWorkerAction
    ...
Caused by: java.lang.NullPointerException
	at com.querydsl.ksp.codegen.QueryModelExtractor.toQueryModel(QueryModelExtractor.kt:115)
	at com.querydsl.ksp.codegen.QueryModelExtractor.addNew(QueryModelExtractor.kt:55)
	at com.querydsl.ksp.codegen.QueryModelExtractor.add$lambda$1(QueryModelExtractor.kt:25)
	at com.querydsl.ksp.codegen.QueryModelExtractor.lookupOrInsert(QueryModelExtractor.kt:42)
	at com.querydsl.ksp.codegen.QueryModelExtractor.add(QueryModelExtractor.kt:24)
	at com.querydsl.ksp.codegen.QueryModelExtractor.addNew(QueryModelExtractor.kt:58)
	at com.querydsl.ksp.codegen.QueryModelExtractor.add$lambda$0(QueryModelExtractor.kt:19)
	at com.querydsl.ksp.codegen.QueryModelExtractor.lookupOrInsert(QueryModelExtractor.kt:42)
	at com.querydsl.ksp.codegen.QueryModelExtractor.add(QueryModelExtractor.kt:19)
	at com.querydsl.ksp.codegen.QueryDslProcessor.process(QueryDslProcessor.kt:22)
	at com.google.devtools.ksp.impl.KotlinSymbolProcessing$execute$1$1.invoke(KotlinSymbolProcessing.kt:549)
	at com.google.devtools.ksp.impl.KotlinSymbolProcessing$execute$1$1.invoke(KotlinSymbolProcessing.kt:547)
	at ksp.com.google.devtools.ksp.common.IncrementalContextBase.closeFilesOnException(IncrementalContextBase.kt:409)
	at com.google.devtools.ksp.impl.KotlinSymbolProcessing.execute(KotlinSymbolProcessing.kt:547)
	at com.google.devtools.ksp.impl.KSPLoader$Companion.loadAndRunKSP(KSPLoader.kt:37)
	at com.google.devtools.ksp.impl.KSPLoader.loadAndRunKSP(KSPLoader.kt)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at com.google.devtools.ksp.gradle.KspAAWorkerAction.execute(KspAATask.kt:548)
       ...

To Reproduce
I created 2 github repositories to reproduce the issue:

1. https://github.com/knmueller/commonLib - This holds the BaseEntity and shows KSP/Querydsl working correct INSIDE the same project with ChildEntity
2. https://github.com/knmueller/service - This holds ChildServiceEntity and shows the NPE when trying to build. Note, there is an includeBuild in settings.gradle.kts to pull in commonLib

Steps to reproduce the behavior:

1. Clone both projects, side by side in the same directory (so includeBuild works)
2. Sync gradle
3. Build the service project - ./gradlew build
4. See NPE during KSP processing

Expected behavior
The Querydsl library should not crash during KSP processing.

Additional context
This seems to be an issue (from a naive perspective) with the !! operator on the QueryModelExtractor.toQueryModel() when it tried to set:

originatingFile = classDeclaration.containingFile!!

Through a debugger, I see that ChildServiceEntity gets correctly processed, but when trying to resolve the parent entity BaseEntity, the classDeclaration.containgFile is null. I am assuming the issue lies in the fact BaseEntity is in a separate library. NOTE - The issue does NOT present itself if the Child and Base Entity are in the same project. This is also shown in the "commonLib" repository with ChildEntity.

[kylequera]

Follow up -- A quick google found me this paragraph: https://medium.com/@umpteenthdev/kotlin-symbol-processing-from-theory-to-practice-e85f980eb67e#:~:text=The%20KSDeclaration.containingFile,our%20simple%20project and a comparison to how the Dagger component handles null containingFile:

The KSDeclaration.containingFile property is nullable. It is possible to get null if the node is declared in a .class file, meaning in the already compiled code. For example, you can find any Dagger component, get its @dagger.Component annotation, and try to get the containing file of the annotation declaration. It is null due to the declaration in the compiled library. To simplify the implementation, we will skip nodes without file, no matter if this is impossible in our simple project.

Not sure if this is a simple solution to skip those components containing a null containingFile.

Please let me know if you have any insight, and I can make an attempt at a fix. Thanks!

[kylequera]

Another follow up - Opened a PR with a fix (#865)

I first tried to just skip the super classes (see previous comment). While this allowed the build to complete and pass the NPE, the parent entity from the external library did not generate (not surprisingly, i guess). The fix I pushed allowed the nullable containingFile locally in querydsl, but when the model is written out on finish, the null containingFile is ignored. This allowed full build and Q class generation for all expected entities.

[github-actions]

This issue has been automatically marked as stale due to inactivity. If no further action is taken, it will be closed in 7 days.

[github-actions]

This issue has been automatically closed due to prolonged inactivity.