-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Resolve several issues in generated Go code #8491
Conversation
9369c07
to
ec11480
Compare
I don't understand why this fails. The go tests run locally fine. Any ideas? |
@antihax @grokify @kemokemo @jirikuncar this patch includes some major improvements to the Go generated client code. It resolves several bugs and improves readability of the consumed go code by using best practice, idiomatic, Go patterns. I would appreciate a review and potentially some help around resolving the CI issue as I can not reproduce it locally! |
I know that reviewing large PRs is very straining. Unfortunately, the Go generator is simply broken at the moment and this PR addresses so many issues in the generated code. I would be really happy to get some pointers what I need to do next in order to get this PR through. |
I'm also getting 405/404 errors when running the integration tests. When I checked it out, the tests were running against the server "petstore.swagger.io". Looking at what happens during the CI script, it adds this entry to /etc/hosts Then it starts a docker container "swaggerapi/petstore" which I guess is the local server that we need, so the tests are communicating with the server inside the docker image Here's the CI script @aeneasr is it worth a try with a similar setup to see if something obvious is going causing the test failure? |
@aeneasr Thanks again for the PR. Let me review shortly. We were busy with the v5.1.0 release. |
_ioutil "io/ioutil" | ||
_nethttp "net/http" | ||
_neturl "net/url" | ||
"context" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if one of the parameter names in the operation is context
? Will that result in issues after this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iirc all methods used are upper-case as they would not be exported otherwise, meaning that context
can not conflict with one of those. However, I might have missed something - do you have a specific place in mind that could conflict here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so I looked into this. The thing is, context
is only used in a few places - primarily in structs, variable declarations, and function signatures:
type AdminApiApiCreateIdentityRequest struct {
ctx context.Context
ApiService *AdminApiService
createIdentity *CreateIdentity
}
var (
_ context.Context
)
func (a *AdminApiService) CreateIdentity(ctx context.Context) AdminApiApiCreateIdentityRequest {
return AdminApiApiCreateIdentityRequest{
ApiService: a,
ctx: ctx,
}
}
In all of those cases there can never be an overshadowing variable clash. So yes, this is safe!
@@ -447,6 +447,13 @@ func reportError(format string, a ...interface{}) error { | |||
return fmt.Errorf(format, a...) | |||
} | |||
|
|||
// Prevent trying to import "bytes" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you mean by this. Any issues using bytes
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, this is a bit confusing. The problem is that in another file bytes
might or might not be needed as an import. By defining the function here, as bytes is always required then, we avoid unused import / undefined import. This is the same as fmt.Errorf
but the comment can probably be improved:
// Prevent trying to import "bytes" | |
// A wrapper for strict JSON decoding |
@@ -1,14 +1,16 @@ | |||
// {{classname}} - {{#description}}{{{description}}}{{/description}}{{^description}}struct for {{{classname}}}{{/description}} | |||
type {{classname}} struct { | |||
{{#oneOf}} | |||
{{{.}}} *{{{.}}} | |||
{{#lambda.titlecase}}{{{.}}}{{/lambda.titlecase}} *{{{.}}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a mininal spec to show the issue related to this fix?
We may better fix it in the Go client generator (java class) instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, so the problem is if we have simple types in the oneOf (bool, float, string) as we generate
type UiNodeInputAttributesValue struct {
bool *bool
float32 *float32
string *string
}
from
"uiNodeInputAttributesValue": {
"oneOf": [
{
"type": "string"
},
{
"type": "number"
},
{
"type": "boolean"
}
]
},
Using the upper case variant here fixes that:
type UiNodeInputAttributesValue struct {
Bool *bool
Float32 *float32
String *string
}
b30cbed
to
29ecad8
Compare
Thank you for your help! I've addressed everything, and tests now pass also. From my side this is good to go :) We will be switching to this generator for all of https://github.com/ory/ / https://www.ory.sh and given that we have large and complex api specs I'll very likely come back with more fixes and improvements :) |
Improves the way pass-by-value and pass-by-reference variables are used. Closes OpenAPITools#8489
If polymorphism without discriminator was used, the previous code was unable to properly decode the vaules. By using a strict decoder, which rejects unknown fields, type guessing now works.
Looks like this just won't get addressed @wing328 , so I'll just go ahead and close this! |
This PR is a lot of work and has lots of nice improvements, thanks @aeneasr. |
Thank you @tbalthazar ! I have been asked by several people to reopen the PR in hopes it gets merged at some point. So reopening! @wing328 I know how difficult it is to maintain such a large project. �If there's anything I can do to help and get things resolved please let me know. I'll do my best :) |
@aeneasr first of all thanks again for the PR. I left some feedback before but didn't have time to review your replies. Can you please merge the latest master into your branch and I'll try to take another look this week? Thanks again for your work. |
No problem, I'll get on it immediately! |
# Conflicts: # modules/openapi-generator/src/main/resources/go/api.mustache # modules/openapi-generator/src/main/resources/go/model_simple.mustache # samples/client/petstore/go/go-petstore/api_another_fake.go # samples/client/petstore/go/go-petstore/api_fake.go # samples/client/petstore/go/go-petstore/api_fake_classname_tags123.go # samples/client/petstore/go/go-petstore/api_pet.go # samples/client/petstore/go/go-petstore/api_store.go # samples/client/petstore/go/go-petstore/api_user.go # samples/openapi3/client/extensions/x-auth-id-alias/go-experimental/api_usage.go # samples/openapi3/client/petstore/go/go-petstore/api_another_fake.go # samples/openapi3/client/petstore/go/go-petstore/api_default.go # samples/openapi3/client/petstore/go/go-petstore/api_fake.go # samples/openapi3/client/petstore/go/go-petstore/api_fake_classname_tags123.go # samples/openapi3/client/petstore/go/go-petstore/api_pet.go # samples/openapi3/client/petstore/go/go-petstore/api_store.go # samples/openapi3/client/petstore/go/go-petstore/api_user.go # samples/openapi3/client/petstore/go/go-petstore/model_nullable_class.go
@wing328 issues resolved, CI passes! It's good to go! :) |
modules/openapi-generator/src/main/resources/go/model_simple.mustache
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: can you please replace spaces with a tab?
Co-authored-by: Jiri Kuncar <[email protected]>
Co-authored-by: Jiri Kuncar <[email protected]>
Done :) |
CI passed again, everything green, good to go! :) |
@jirikuncar thanks for reviewing the change. @aeneasr thanks again for your work. Can you please PM me via Slack for a few quick questions when you've time? https://join.slack.com/t/openapi-generator/shared_invite/enQtNzAyNDMyOTU0OTE1LTY5ZDBiNDI5NzI5ZjQ1Y2E5OWVjMjZkYzY1ZGM2MWQ4YWFjMzcyNDY5MGI4NjQxNDBiMTlmZTc5NjY2ZTQ5MGM My timezone is +0800 (Hong Kong). |
Tested locally and the result is good. Thanks for the PR and sorry again for the delay in reviewing the change |
@wing328 thank you so much for reviewing and merging this and reaching out on Slack!! |
This PR resolves several generated Go-client code issues which resolve compilation errors, improve return and field types (pointer vs value) to better match idiomatic Go-style.
Closes #8489
See #8489
See #8485
PR checklist
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*
.For Windows users, please run the script in Git BASH.
master
,5.1.x
,6.0.x
@antihax @grokify @kemokemo @jirikuncar