[BUG] Mismatch between open-api and JSON

[tdroxler]

Tapir version: *** 1.0.6 and above

Scala version: *** 2.13 Describe the bug

https://github.com/softwaremill/tapir/pull/2403 is creating mismatch between openapi and json (using upickle) I kinda disagree with the behavior expected here https://github.com/softwaremill/tapir/issues/2358 I don't know which json lib was used, but a least with upickle, if you define a @upickle.implicits.key(Person) and convert to json as a Person or as an Entity, in both case you'll have the discriminator. This might not be an issue in case of a GET, but if in the example above we need to POST a Person, if we don't give the discriminator : "Person", the json deserialization will fail. How to reproduce?

At alephium we are happily using tapir, I created this commit where I updated to 1.0.6, we can see the new type Name1 being created. I concentrate my example on the AssetOutput as I'm using it directly and not as an Output it creates the AssetOutput1 schema. I don't have yet an endpoint where I POST an AssetOutput, but I can already tell that upickle won't be able to read it if there are no discriminator, shown in this commit you can run

app/testOnly org.alephium.explorer.api.model.ApiModelSpec -- -z "AssetOutput"

IMO this is an issue, we have a front-end team that is generating there TypeScript types from the open-api file and in that above case, they will need to used AssetOutput1 to POST and it will fail.

Additional information

[adamw]

I think the relevant changes here are #2358, #2403 simply adds support for an alternative coproduct serialisation strategy, which doesn't influence the existing ones.

The problem is: what's the schema of Person in your code? If you do Schema.derived[Person], you won't get the discriminator field. Which doesn't match what upickle expects, and is the core problem that has to be fixed. You can customise the schema using the @customise annotation, but there are other ways as well: https://tapir.softwaremill.com/en/latest/endpoint/schemas.html#customising-derived-schemas