Skip to content
New issue

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

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

Already on GitHub? # 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)

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

No branches or pull requests

3 participants