square/moshi

Moshi Codegen doesn't work with OpenAPI 3.1.0

Closed this issue · 7 comments

Summary
Attempting to parse an OpenAPI JSON file with version 3.1.0 results in multiple errors originating from com.squareup.moshi.kotlin.codegen.ksp in the Android platform.

Expected Behavior
The OpenAPI JSON file should be parsed successfully without errors, as it works on other platforms.

Actual Behavior
Parsing the OpenAPI JSON file results in multiple errors, all starting with "[ksp] Error preparing", specifically from com.squareup.moshi.kotlin.codegen.ksp. Examples of the errors include:

[ksp] Error preparing Account: com.squareup.moshi.kotlin.codegen.ksp.AppliedType.superclasses(AppliedType.kt:46)

[ksp] Error preparing ApplicationConfirmProductPostRequest: com.squareup.moshi.kotlin.codegen.ksp.AppliedType.superclasses(AppliedType.kt:46)

[ksp] Error preparing ApplicationCreateOrResumePostRequest: com.squareup.moshi.kotlin.codegen.ksp.AppliedType.superclasses(AppliedType.kt:46)

Environment
OpenAPI version: 3.1.0
Moshi codegen: 1.15.1
Android platform

Additional Context
The issue seems to be specific to the Android platform, as the same OpenAPI JSON file have been parsed correctly on other platforms. The errors point to issues in the com.squareup.moshi.kotlin.codegen.ksp.AppliedType.superclasses method.

No idea what this is nor have you offered any meaningful information, error messages, or repro cases to indicate this is a bug in Moshi. Please take it up with whoever maintains the API generator you're using.

@ZacSweers I have 64 errors which are pointing to moshi library. Some of them I added to the post.

Here is the more detailed information from one of them:

[ksp] Error preparing Def10AnyOf: com.squareup.moshi.kotlin.codegen.ksp.AppliedType.superclasses(AppliedType.kt:46) com.squareup.moshi.kotlin.codegen.ksp.TargetTypesKt.targetType(TargetTypes.kt:111) com.squareup.moshi.kotlin.codegen.ksp.JsonClassSymbolProcessor.adapterGenerator(JsonClassSymbolProcessorProvider.kt:118) com.squareup.moshi.kotlin.codegen.ksp.JsonClassSymbolProcessor.process(JsonClassSymbolProcessorProvider.kt:92) com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension$doAnalysis$8$1.invoke(KotlinSymbolProcessingExtension.kt:310) com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension$doAnalysis$8$1.invoke(KotlinSymbolProcessingExtension.kt:308) com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension.handleException(KotlinSymbolProcessingExtension.kt:414) com.google.devtools.ksp.AbstractKotlinSymbolProcessingExtension.doAnalysis(KotlinSymbolProcessingExtension.kt:308) org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration(TopDownAnalyzerFacadeForJVM.kt:112) org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration$default(TopDownAnalyzerFacadeForJVM.kt:75) org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyze$lambda$12(KotlinToJVMBytecodeCompiler.kt:373) org.jetbrains.kotlin.cli.common.messages.AnalyzerWithCompilerReport.analyzeAndReport(AnalyzerWithCompilerReport.kt:115) org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyze(KotlinToJVMBytecodeCompiler.kt:364) org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.runFrontendAndGenerateIrUsingClassicFrontend(KotlinToJVMBytecodeCompiler.kt:195) org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli(KotlinToJVMBytecodeCompiler.kt:106) org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:176) org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:50) org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:104) org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:48) org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:101)

Could the problem be because in v3.0 the way how the type is defined is different than in v 3.1 ?

image image

Still completely unhelpful. Either link a minimally reproducing sample project that clearly indicates this is a bug in Moshi or we can't help you, sorry!

Created the project where during the build you can reproduce the issue

https://github.com/edharkhimich/test-openapi

Check the 'master' branch last commit

You still haven't explained why you feel this is a bug in moshi? In your previous message you even call out that this is a behavior difference between different versions of the other tool you're using.

Because all the errors are pointing to moshi library.
Looks like it can't parse the obj during the code generation.

In one of my previous messages I asked the question about the version difference and can it be the problem.

Sorry, I know nothing about the library you're linking or how it interacts with Moshi. Please take it up with them.