-
Notifications
You must be signed in to change notification settings - Fork 58
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
Uninformative error on self-conflicting types #485
Comments
Btw, some other OpenAPI codegens resolve the conflict between |
Thank you for the isolated reproduction, and sorry about the unhelpful nature of the message there. This does indeed seem like a conflict -- what does it say in the prose documentation for the part of the API that the broken schema describes? That is: are they actually expecting a string or an object? |
The spec and the documentation is autogenerated based on annotations in some Java code that I'm not very familiar with. |
It's important to note, though, that only Java classes extending |
I've moved this to the typify repo since the code it pertains to lives here. Progenitor hands of processing of types to typify. First, yes, the error message need to be improved. There's ongoing work to maintain context so that, in a case such as this one, the error pointed you to the specific part of the large specification document where the problem was encountered. It seems like the schema for Bar is wrong for its intended use. Perhaps it should be something like: "Bar": {
"properties": {
"value": {}
}
} or (equivalently): "Bar": {
"properties": {
"value": true
}
} I'm not sure what weight to put on the fact that Bar isn't used directly. In general, typify (and progenitor) studiously avoid heuristic handling of potentially misconstructed schemas. Specifically, when a schema is innately unsatisfiable, there is no intrinsically correct answer regarding which constraints one might relax to resolve that unsatisfiability. In fact, the direction we've been going is to use "never" types in situations such as these ( My general recommendation has been to apply a JSON patch to the input document before passing it to progenitor (or to typify). |
I agree. My solution for now is to preprocess the schema in build.rs, as it is the schema that is wrong. I don't think a lot of context is necessary, although I wouldn't exactly complain about a rustc-style error message with line numbers and everything. It might be enough to state the name of the type that couldn't be determined. Just knowing that |
Absolutely: I really just want to give you a json path since some specs don't contain newlines so saying "somewhere on line 1" wouldn't be helpful. |
I think #521 might also be somewhat useful here. |
I used the following OpenAPI schema:
I expected an error saying that the type of
value
inFoo
was ambiguous. I got:It seems silly in this example, but the original schema was 10000 lines long, so it was quite tedious to isolate the issue.
Meta
Progenitor version used was 0.5.0.
I used a build.rs file to invoke progenitor.
The text was updated successfully, but these errors were encountered: