Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

text/plain response referencing component of string enum creates uncompilable code in Java #1909

Open
lukeramsden opened this issue Jan 2, 2024 · 2 comments

Comments

@lukeramsden
Copy link

Here is a minimal recreation of the issue, tested using the integration tests locally. This is a heavily trimmed down version of Supertokens' FDI schema in its resolved form.

openapi: 3.0.0
info:
  title: Whatever
  version: 1.0.0
servers:
  - url: //localhost:1234/foo/
paths:
  /blah/blah:
    post:
      description: Do something!
      operationId: do-something
      responses:
        "500":
          description: error code 500
          content:
            text/plain:
              schema:
                $ref: '#/components/schemas/internalError'
components:
  schemas:
    internalError:
      type: string
      enum:
        - Internal Error

It logs warnings:

[info] WARNING: Don't know how to handle response of type issues.issuedraft.client.dropwizardVavr.definitions.InternalError for content type text/plain at .paths./blah/blah.operations.POST; falling back to String
[info] WARNING: Don't know how to handle response of type issues.issuedraft.client.dropwizard.definitions.InternalError for content type text/plain at .paths./blah/blah.operations.POST; falling back to String

And then fails with a compilation error:

[error] /Users/lukeramsden/workspace/guardrail/modules/sample-dropwizard/target/generated/issues/issuedraft/client/dropwizard/Client.java:96:1: incompatible types: java.lang.String cannot be converted to issues.issuedraft.client.dropwizard.definitions.InternalError
[error] response
[error]                                     .getResponseBody(AsyncHttpClientUtils.getResponseCharset(response)
[error]                                             .orElse(StandardCharsets.UTF_8))
[error] (sample-dropwizard / Compile / compileIncremental) javac returned non-zero exit code

It's quite easy to find where this code is generated (here https://github.com/guardrail-dev/guardrail/blob/e3c9b944ed2228a49bac03581d8b0ddc09ed3098/modules/java-async-http/src/main/scala/dev/guardrail/generators/java/asyncHttpClient/AsyncHttpClientClientGenerator.scala#L860C67-L860C67) but not clear to me if this is invalid OAS3 (the linters I can find all seem to allow it) or just a missing case here - if the body value type is an enum, I would expect it to use the object mapper to read it even for text/plain?

@blast-hardcheese
Copy link
Member

Certainly an edge case, thanks for reporting it! A lot of my effort has gone towards the guardrail ecosystem more broadly recently, increasing stability between modules in preparation for the 1.0 launch, so I don't have time to work on this right now, my apologies.

You may be able to work around this using x-server-raw-response: true to annotate the broken routes, though you may need to comment out the $ref as well in order to get the response infrastructure to not be generated.

openapi: 3.0.0
info:
  title: Whatever
  version: 1.0.0
servers:
  - url: //localhost:1234/foo/
paths:
  /blah/blah:
    post:
      description: Do something!
      operationId: do-something
      x-server-raw-response: true
      responses:
        "500":
          description: error code 500
          content:
            text/plain:
              schema:
                type: string
                # $ref: '#/components/schemas/internalError'
components:
  schemas:
    internalError:
      type: string
      enum:
        - Internal Error

You may additionally be able to get by without x-server-raw-response if you swap the $ref with type: string as well, doing the marshalling yourself, though x-server-raw-response is the sledgehammer to get you unblocked.

Sorry you ran into this, hope my suggestions here help!

@lukeramsden
Copy link
Author

I'll take a look, thank you. Great work on guardrail by the way, was much easier to get to this point than any other Java OAS tooling, even if I did hit an edge case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants