Hardcoded 400 for default status

[jducoeur]

Context: https://softwaremill.community/t/how-best-to-go-about-proposing-and-helping-with-code-generation-improvements/542

Tapir version: 1.13.19

If you specify a result type's status code as 'default' (fairly ordinary OpenAPI, which we do a lot), the generated code assumes that that means StatusCode(400). I believe that's incorrect, isn't it? AFAIK, default means "any other status code".

It can result in weirdness like

responses:
  '200':
    description: Success
    content:
      text/plain:
        schema:
          type: string
          example: Success
  '400':
    description: Bad parameters
    content:
      text/plain:
        schema:
          type: string
          example: Example bad parameter message
  '404':
    description: Missing a bit
    content:
      text/plain:
        schema:
          type: string
          example: The missing details message
  default:
    description: Any other return code

producing something like

.errorOut(oneOf[String](
  oneOfVariant[String](sttp.model.StatusCode(400), stringBody.description("Bad parameters")),
  oneOfVariant[String](sttp.model.StatusCode(404), stringBody.description("Missing a bit")),
  oneOfVariant[String](sttp.model.StatusCode(400), stringBody.description("Any other return code"))))

which is obvious nonsense.

On the server side that doesn't matter too much, since you should always try to explicitly specify the codes that could be produced.

But if you're generating stubs for client use, this detail appears to make them kind of unusable: that all-important fall-through case isn't covered properly. That matters, since it's not unusual to get unexpected return code thanks to proxies and suchlike.

This can probably be hacked around on the client side, but I not clear on what that looks like, and it's certainly not ideal. Conceptually, it seems like this wants the generic non-specific statusCode, not StatusCode(400), doesn't it?

This problem is a bit lower-priority for us, since we don't have immediate plans to use Tapir code generation for client-side. But we'd like to have the door open to do so, and this one feels like a just-plain-bug to me -- I'm not clear why it works the way it does, although the code generator's own code makes it look like it's intentional.

As with the others, happy to help work on solving this.

[adamw]

This seems somewhat related to #5284 - maybe let's wait until that one is solved

[hughsimpson]

@adamw what should default error look like in tapir? Like, if I wanted to actually have default, is there a DefaultError or something? Sorry afk until Monday and I can't search code without an ide I'm useless like that

[adamw]

@hughsimpson "default" in the sense of an openapi spec? I guess it would mean "for any other status code, the response looks like this: ...", right? So translating to Tapir, this would be an output variant with an arbitrary status code (as in, statusCode output), paired with whatever the response's shape is. Alternatively, not to require the status code, you could have a catch-all variant that's present at the end of the list of variants, with a fixed status code of 400.

[hughsimpson]

OK. That's helpful, thanks!