-
-
Notifications
You must be signed in to change notification settings - Fork 248
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
Broken code generation for empty enums #1253
Comments
See my comment in the other issue, that's an invalid schema. We won't be able to generate a proper query for it. |
Thank you! Does it make sense to fail early while parsing the schema? That way you get a proper error message. It is already the case when you try the generate code for |
Let's catch that case and fail with a nice error message rather than generating code that doesn't compile. |
I can take this issue on. From a preliminary investigation, I can see that there does appear to be some early validation for non-empty enum values in caliban/core/src/main/scala/caliban/validation/Validator.scala Lines 739 to 747 in a1673fe
So I'm wondering why this doesn't appear to be catching the case where there's an empty enum. That said, I'm not super familiar with the system. It looks like the place to catch it would likely be in |
@jyoo980 that would be in ClientWriter.scala |
Got it, I see this function caliban/tools/src/main/scala/caliban/tools/ClientWriter.scala Lines 664 to 668 in a1673fe
A pretty hacky way of catching an empty enum would be to add something like require(typedef.enumValuesDefinition.nonEmpty, s"Code generation for empty enum '${typedef.name}' failed") to line 668, but that doesn't seem quite right, do you have any recommendations? It's pretty difficult to see failure cases for this specific object since I think it's predicated on the assumption that most invariants are checked beforehand. That said, there does seem to be some precedent for this kind of early escape hatch; line 580 throws an exception when codegen is attempted for an object with less than one field:
Do you have a preference? |
I think it's fine to fail like on line 589 👍 |
I'd be happy to add some tests. Do you have any pointers? Mixing exceptions with functional effects makes thing kinda hairy; I don't think there's a super nice way of testing this as it is right now. |
In |
Interesting, I have something like testM("enum with no body") {
val schema =
"""
enum Origin { }
""".stripMargin
assertM(ZIO.effect(gen(schema)).run)(fails(isSubtype[Exception](anything)))
}, Which yields
Strange, since the |
|
We are working with a hasura-generated schema, which somehow contains empty enums like this one:
But when compiling the generated code, we get this compile error:
I am not sure what an empty enum is supposed to mean. It is only empty when accessing hasura unauthorized, but has values when accessing it authorized.
Should this be supported or is that an invalid schema?
The text was updated successfully, but these errors were encountered: