Endpoint API: OpenAPI documentation generator crashes on parameterized case classes
Describe the bug
With parameterized case class used as endpoint's output, Open API documentation generator crashes.
To Reproduce Steps to reproduce the behaviour:
- Run the following code:
//> using scala 3.4.0
//> using dep dev.zio::zio-http:3.0.0-RC6
import zio.http.Method
import zio.http.endpoint.Endpoint
import zio.http.endpoint.openapi.JsonSchema.SchemaStyle
import zio.http.endpoint.openapi.OpenAPIGen
import zio.schema.{DeriveSchema, Schema}
object OpenAPIBug:
final case class Item(isEdited: Boolean)
given Schema[Item] = DeriveSchema.gen[Item]
final case class Data[A](data: List[A])
given dataSchema[A: Schema]: Schema[Data[A]] = DeriveSchema.gen[Data[A]]
def main(args: Array[String]): Unit = OpenAPIGen.fromEndpoints(SchemaStyle.Reference, List(
Endpoint(Method.GET / "bug").out[Data[Item]]
))
- Observe the following exception:
java.util.NoSuchElementException: None.get
at zio.http.endpoint.openapi.OpenAPIGen$$anon$7.applyOrElse(OpenAPIGen.scala:707)
(Caused by the fact that zio.http.endpoint.openapi.OpenAPI.Key.fromString("Data[A]") returns None.)
Expected behaviour I expect correct Open API documentation to be generated, or, at a minimum, no crashes ;)
I’ve also experienced the same issue as reported.
Update:
I've found a workaround - manually generating the Schema with a simple id.
Example:
given [V <: ValidationStatus]: Schema[CreateItemInput[V]] =
Schema.CaseClass3[String, Money, ProductType, CreateItemInput[V]](
id0 = TypeId.fromTypeName("CreateItemInput"), // <- "simple" id
field01 = Schema.Field(name0 = "name", schema0 = Schema[String], get0 = _.name, set0 = (v, x) => v.copy(name = x)),
field02 =
Schema.Field(name0 = "price", schema0 = Schema[Money], get0 = _.price, set0 = (v, x) => v.copy(price = x)),
field03 = Schema.Field(
name0 = "productType",
schema0 = Schema[ProductType],
get0 = _.productType,
set0 = (v, x) => v.copy(productType = x),
),
construct0 = (name, price, productType) => CreateItemInput[V](name, price, productType),
)
/bounty $150
💎 $150 bounty • ZIO
Steps to solve:
- Start working: Comment
/attempt #2767with your implementation plan - Submit work: Create a pull request including
/claim #2767in the PR body to claim the bounty - Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts
Thank you for contributing to zio/zio-http!
Add a bounty • Share on socials
| Attempt | Started (GMT+0) | Solution |
|---|---|---|
| 🔴 @Anshgrover23 | Jun 14, 2024, 7:20:13 AM | WIP |
| 🟢 @987Nabil | #3022 |
hey i have submitted the pr plss check
I think it would be nice if the name generated for openapi be specified with its type parameters (i.e. Data_String) instead of just Data. Systems that consume the openapi json or yaml file could then generate the correct code for different instances of the parameterized type.
@jdegoes This problem is not solvable in a clean way in zio-http. We need to fix this in zio-schema.
- The Scala 3 macro behaves different then the Scala 2 macro, by adding to the
typeNameof the id[A]for the example given in the issue. This is imo just wrong. - We can't do what @countfloyd suggested -> make the generically filled types part of the OpenAPI schema name. This is because zio-schema does not store this information at all. I think we should store in a Product/Enum schema which generics are filled with which schemas and the fields that are of this generic. Maybe something like
generics: Map[String, GenericInfo]where the key is just the generic name (Ahere) andcase class GenericInfo(implementigSchema: Schema, fieldNames: List[String] ). I guess field names should be enough to do the mapping where needed, for example to get the schema by finding the field with such name.
💡 @987Nabil submitted a pull request that claims the bounty. You can visit your bounty board to reward.