OpenAPITools / OpenAPITools/openapi-generator

[BUG] [Kotlin] [Gradle Plugin] [Android] Generated enum classes expect strings when specification specifies integers

Open
#8,458 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Client: Retrofit Issue: Bug
Dominant language
Java
Stars
26.8k
Forks
7.7k
PR merge metrics
PR metrics pending

Description

Description

I am using the OpenApiGenerator via the Gradle plugin in my Kotlin Android project. I am running into an issue where generated enum classes are expecting strings even though the specification specifies integers. The means Moshi is unable to parse enum values in my sever responses.

Enums in my OpenAPI specification file are of this form:

"MediaType": {
    "enum": [
        0,
        1,
        2,
        3
    ],
    "type": "integer",
    "format": "int32",
    "x-enum-varnames": [
        "unknown",
        "video",
        "audio",
        "text"
    ]
}

The resulting generated enums are of this form:

enum class MediaType(val value: kotlin.Int) {

    @Json(name = "0")
    unknown(0),

    @Json(name = "1")
    video(1),

    @Json(name = "2")
    audio(2),

    @Json(name = "3")
    text(3);
    
    ...
}

This leads to unsuccessful parsing of enums by Moshi. The resulting exception is of this form:

com.squareup.moshi.JsonDataException: Expected one of [0, 1, 2, 3] but was 2 at path $[0].mediaType
      at com.squareup.moshi.StandardJsonAdapters$EnumJsonAdapter.fromJson(StandardJsonAdapters.java:297)
      at com.squareup.moshi.StandardJsonAdapters$EnumJsonAdapter.fromJson(StandardJsonAdapters.java:264)
      at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
      ...
openapi-generator version

classpath "org.openapitools:openapi-generator-gradle-plugin:5.0.0"

OpenAPI declaration file content or url

I am using the following configuration for the Gradle plugin:

openApiGenerate {
    generatorName = "kotlin"
    inputSpec = "$projectDir/openapi-spec.json"
    ignoreFileOverride = "$projectDir/.openapi-generator-ignore"
    outputDir = "$buildDir/generated/openapi"
    apiPackage = "com.example.api.service"
    modelPackage = "com.example.api.model"
    configFile = "$projectDir/openapi-generator-config.json"
}

This is the contents of 'openapi-generator-config.json':

{
  "apiSuffix": "Service",
  "collectionType": "list",
  "enumPropertyNaming": "UPPERCASE",
  "library": "jvm-retrofit2",
  "modelMutable": "false",
  "moshiCodeGen": "true",
  "packageName": "com.example.api",
  "parcelizeModels": "false",
  "serializableModel": "false",
  "sortModelPropertiesByRequiredFlag": "true",
  "sortParamsByRequiredFlag": "true",
  "useCoroutines": "true"
}
Suggest a fix

I am considering writing custom adapters somewhere to handle this manually, but it would be very tedious to have to do this for every single enum type in my spec. Is there an easier solution out there? Unfortunately, I don't have much control over the form the enums are in the specification. For reasons on the back end, I think I am stuck with x-enum-varnames.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with openapi-spec.json, openapi-generator-config.json, and the Gradle openApiGenerate configuration, then reproduce the Kotlin generator output for the integer enum with Moshi code generation enabled. Trace how the Kotlin/Android generator maps enum values to Moshi annotations. Done means generated enums deserialize the integer values from the specification without requiring per-enum custom adapters.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, kotlin, openapi
Domain
backend-api-design, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.