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

[BUG] [scala-sttp] API functions return Unit when a default response is present #15785

Closed
5 of 6 tasks
michaelmcguirk opened this issue Jun 7, 2023 · 3 comments
Closed
5 of 6 tasks

Comments

@michaelmcguirk
Copy link

michaelmcguirk commented Jun 7, 2023

Bug Report Checklist

  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator (example)?
  • Have you tested with the latest master to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?
  • [Optional] Sponsorship to speed up the bug fix or feature request (example)
Description

When using the scala-sttp generator, any paths in the spec which have a default response result in generated API functions that always return Unit for a successful response(Unit in Scala is the equivalent of void in Java).

This is not an issue when the default response does not have a schema, but is incorrect when a default response schema is present, as it hides the response.

The problem is the use of asEither(asString, ignore) here when a spec has a default response on a path with a schema as the ignore portion on the right has the effect of ignoring whatever is on the Right of the Either (the success response).

openapi-generator version

6.4.0

OpenAPI declaration file content or url

https://gist.github.com/michaelmcguirk/0862f22cad0c8fafea9269cbe12ad3dc

Generation Details
openapi-generator-cli generate -i ~/petstore.yaml -g scala-sttp

Steps to reproduce
  1. Run openapi-generator-cli generate on the attached spec using the scala-sttp generator.
  2. Check the showPetsById function in PetsApi.scala in the generated code.
  3. Response type signature should be Request[Either[ResponseException[String, Exception], Pet], Any] as it returns a Pet response, but in fact it is Request[Either[Either[String, String], Unit], Any]
Related issues/PRs

#11949

Suggest a fix

I believe I have a fix, and I'm happy to create a PR, but the contribution guidelines mention opening an Issue first.

Currently api.mustache checks for #defaultReturnType when it could check for ^returnType so that we're only returning unit when a return type is absent here:

.response({{#defaultReturnType}}asEither(asString, ignore){{/defaultReturnType}}{{^defaultReturnType}}{{#separateErrorChannel}}asJson{{/separateErrorChannel}}{{^separateErrorChannel}}asJsonAlwaysUnsafe{{/separateErrorChannel}}[{{>operationReturnType}}]{{/defaultReturnType}})

Updated api function response would be:

.response({{^returnType}}asEither(asString, ignore){{/returnType}}{{#returnType}}{{#separateErrorChannel}}asJson{{/separateErrorChannel}}{{^separateErrorChannel}}asJsonAlwaysUnsafe{{/separateErrorChannel}}[{{>operationReturnType}}]{{/returnType}})

with the function signature being:

Request[{{^returnType}}Either[Either[String, String], Unit]{{/returnType}}{{#returnType}}{{#separateErrorChannel}}Either[ResponseException[String, Exception], {{>operationReturnType}}]{{/separateErrorChannel}}{{^separateErrorChannel}}{{>operationReturnType}}{{/separateErrorChannel}}{{/returnType}}, Any] 
@dwischolek-modulon
Copy link
Contributor

This is still an issue. If it helps, I could try to create a PR sometime next week.

@dwischolek-modulon
Copy link
Contributor

@wing328 I think this might be closed with the two PRs merged.

@wing328 wing328 closed this as completed May 2, 2024
@wing328
Copy link
Member

wing328 commented May 2, 2024

Thanks for the PR by @dwischolek-modulon

@michaelmcguirk please give it a try with the latest master (snapshot version can be found in project's readme)

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

No branches or pull requests

3 participants