is there a verbose mode to diagnose errors?
Is there a verbose flag or a way to see line numbers/more info/etc for generation failures?
eg
oapi-codegen -package indexapi apis/openapi_resolved.yaml > indexapi.gen.go
error loading swagger spec in apis/openapi_resolved.yaml
: error unmarshaling JSON: while decoding JSON: json: cannot unmarshal number into Go struct field TBis.components of type bool⏎
it's hard for me to really fix or diagnose this from a 4000 line openapi.yaml from that alone
@tommyjcarpenter were you able to figure this out? having the same issue
@bernii yes, although not using this package directly.
I; 1 loaded up the openapi.yaml in the swagger error and fixed all the warnings I could 2 Added back one endpoint at a time, until I found the offending block
I forget what the actual issue was but it was something very simple like float/number
I do think a verbose generation mode, if possible, would be a huge help
I had the same problem and found this issue.
In my case, the @tommyjcarpenter tip helped me see that I was putting the required: attribute in the wrong place.
I went to https://editor.swagger.io/, added my spec and got all my errors highlighted :)
how it was:
NewTranslation:
properties:
word:
type: string
description: The word to be translated
required: true
language:
type: string
description: The language of the word to be translated
required: true
translation:
type: string
description: The translation of the word
required: true
how it should be:
NewTranslation:
required:
- word
- language
- translation
properties:
word:
type: string
description: The word to be translated
language:
type: string
description: The language of the word to be translated
translation:
type: string
description: The translation of the word
Yeah this is definitely something that'd be good to fix. As an example, https://ogen.dev/ provides a nice error format:
% go run github.com/ogen-go/ogen/cmd/ogen@latest --target petstore --clean petstore-expanded.yaml
- petstore-expanded.yaml:7904:33 -> cannot unmarshal !!float `0.0` into bool
7901 | },
7902 | "steps": {
7903 | "title": "Steps",
→ 7904 | "exclusiveMinimum": 0.0,
7905 | "type": "integer",
7906 | "description": "Number of steps to run",
7907 | "default": 10,
7908 | "input": "any",
- petstore-expanded.yaml:11561:33 -> cannot unmarshal !!float `0.0` into bool
11558 | },
11559 | "width": {
11560 | "title": "Width",
→ 11561 | "exclusiveMinimum": 0.0,
11562 | "type": "integer",
11563 | "description": "The width of the crop rectangle",
11564 | "default": 512,
11565 | "input": "any",
- petstore-expanded.yaml:12583:33 -> cannot unmarshal !!float `0.0` into bool
12580 | },
12581 | "width": {
12582 | "title": "Width",
→ 12583 | "exclusiveMinimum": 0.0,
12584 | "type": "integer",
12585 | "description": "The width to resize to (px)",
12586 | "default": 512,
12587 | "input": "any",
- petstore-expanded.yaml:12700:33 -> cannot unmarshal !!float `0.0` into bool
12697 | },
12698 | "scale_factor": {
12699 | "title": "Scale Factor",
→ 12700 | "exclusiveMinimum": 0.0,
12701 | "type": "number",
12702 | "description": "The factor by which to scale the image",
12703 | "default": 2.0,
12704 | "input": "any",
- petstore-expanded.yaml:13134:33 -> cannot unmarshal !!float `0.0` into bool
13131 | },
13132 | "downscale": {
13133 | "title": "Downscale",
→ 13134 | "exclusiveMinimum": 0.0,
13135 | "type": "number",
13136 | "description": "Run patchmatch on downscaled image to speedup infill",
13137 | "default": 2.0,
13138 | "input": "any",
generation failed:
main.run
/home/jamie/go/pkg/mod/github.com/ogen-go/[email protected]/cmd/ogen/main.go:302
exit status 1
I usually process my specs through https://github.com/daveshanley/vacuum or https://github.com/stoplightio/spectral when I see issues
I think all I was looking for here is a verbose mode or an actual line number/object name where the parsing error occured; I assume the eventual stacktrace knows what object it was trying to parse when it exploded, so if that could propagate through, even if it only has the component name and doesn't contain the actual error ("required property X is missing" for example), debugging time would go way down
So looking at how we parse the OpenAPI spec, under the hood it's https://github.com/getkin/kin-openapi/blob/bfab8b04683ff684a7595e6003796ae2b7a915aa/openapi3/openapi3.go#L55-L60 which doesn't give much back in the way of errors, unfortunately :disappointed:
We can definitely work to improve it, but right now, that's why it's not ideal output