OpenAPI - GetEthV1ValidatorBlocksWithSlot declared twice

[xrn]

From Go when I am using

openapi-generator generate --skip-validate-spec -i https://consensys.github.io/teku/latest.json -g go -c ./clients/teku/openapi_config.json -o ./clients/teku/tekuapi

I am getting two files api_validator_required_api.go and api_validator_api.go both are implementing same items - for example

// GetEthV1ValidatorBlocksWithSlotOpts Optional parameters for the method 'GetEthV1ValidatorBlocksWithSlot'
type GetEthV1ValidatorBlocksWithSlotOpts struct {
	Graffiti optional.String
}

I think it should be kept with one of them or moved to a separate file

[rolfyone]

thanks for raising this one, I'll have a look.

[rolfyone]

So it looks like api_validator_required_api.go is an export of the 'Validator Required Api' heading, and api_validator_api.go is the 'Validator Api' heading.

They do come down to 1 implementation, but its got 2 category headings, which is pretty normal in OpenApi.

I would probably suggest only importing the api_validator_api.go, as its a superset of the required api. Some of the other parts of the required api live in the beacon group, so you might want to make use of those from that area also.

The standard api is written by hand into yaml, so you may be able to make use of that, which will probably come out cleaner because of the way it's been written. https://ethereum.github.io/eth2.0-APIs/

It does appear that there's projects mentioning similar to this issue, and they come down to requiring a swagger change.
OpenAPITools/openapi-generator#2701

I've upgraded swagger, javalin on our end, but it didn't stop the reported problem, so I'll hold off from any merge for that change.

Hopefully there's bits of this that are of use, but currently there appears to be not a lot we can actually do to help rectify this issue on our end.

[xrn]

Thanks, @rolfyone for the deep explanation. Everything clear - from my side we can close this issue if you would like to keep it as a reference feel free

[rolfyone]

It's still accessible once closed, so I'll close it out. Glad that my explanation was helpful, but I was still really hoping to be able to actually make it work for you in preference to explain the complications.

If you do use the standard spec and any issues come out of that, please feel free to raise, as we are definitely aiming to keep compliant with the standard specification.