test(go): add test for RESOLVE_INLINE_ENUMS #21623

sruehl · 2025-07-24T09:33:30Z

The PR added a unit test to demonstrate missing enums as defined in #9567. To validate one can uncomment line 117 in GoClientCodegen.java and then the tests will fail.

@antihax @grokify @kemokemo @jirikuncar @ph4r5h4d @lwj5

PR checklist

Read the contribution guidelines.
Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
Run the following to build the project and update samples:
```
./mvnw clean package || exit
./bin/generate-samples.sh ./bin/configs/*.yaml || exit
./bin/utils/export_docs_generators.sh || exit
```
(For Windows users, please run the script in WSL)
Commit all changed files.
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*.
IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

sruehl · 2025-07-24T09:38:13Z

set to draft for now as it seems that at the moment Enum names collide. This is not unique to inline enums so I wonder how that is solved in general. Any ideas how to fix that @antihax @grokify @kemokemo @jirikuncar @ph4r5h4d @lwj5?

sruehl · 2025-07-24T09:39:40Z

also on the note of a "breaking" change. It is breaking and kind of not: The enums have the base type as before so from a user perspective a missing cast is required if the base types are being used. The non-breaking part is that it is still the same more or less. For that reason I was unsure if it is now breaking or non breaking.

sruehl · 2025-09-02T07:51:19Z

@wing328 is anyone of the Go Maintainers still active?

sruehl · 2025-09-02T07:52:01Z

have another issue to fix regarding xml instructions being completely ignored but if none of the maintainers react it is not worth putting time into that...

wing328 · 2025-09-02T08:00:49Z

your PR is still a draft

that's why I've not yet found the time to review this change.

can you please PM me via Slack if you need further assistance to get this PR ready to be reviewed?

wing328 · 2025-09-02T08:01:48Z

It seem when using the option RESOLVE_INLINE_ENUMS they are getting generated.

as you mentioned, if you've the option enabled, it works fine for your use cases or still an issue with the option enabled?

sruehl · 2025-09-02T09:59:23Z

@wing328 all good, the question was directed at the fact that none of the go maintainers tried to look at the PR. I set the PR to read for review just now

wing328 · 2025-09-02T10:13:03Z

can you please review the build failure when you've time?

wing328 · 2025-09-02T10:14:48Z

modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/GoClientCodegen.java

@@ -113,6 +113,9 @@ public GoClientCodegen() {
        outputFolder = "generated-code/go";
        embeddedTemplateDir = templateDir = "go";

+        // We need inline enums to be resolved to a separate model
+        inlineSchemaOption.put("RESOLVE_INLINE_ENUMS", "true");


what about checking if the key RESOLVE_INLINE_ENUMS is already set (true or false) before defaulting it to true so that users have a way to fallback?

what about using containsKey method?

also let's not do this in the constructor

please do it in processOpts instead

ok, will do once we have a con sense how to handle the default situation.

sruehl · 2025-09-02T10:20:55Z

can you please review the build failure when you've time?

sure. It fails because of #21623 (comment)

wing328 · 2025-09-03T07:14:07Z

set to draft for now as it seems that at the moment Enum names collide.

if enum is just a model, then the modelNameMapping option may help

https://github.com/openapitools/openapi-generator/blob/master/docs/customization.md#name-mapping

sruehl · 2025-09-03T08:23:35Z

I think for this PR I can change one of the enums to SUPER_SUCCESS. The problem is, like I said, not related to the change or this PR it is rather a general problem how Golang works. In Java you always qualify your enum with the enum name (A.SUCCESS, B.SUCCESS). In Golang there are no enums, just named constants. So the SUCCESS is just dumped into the package. So I think to make the build pass I rename one of the enums and then we should add a second feature/option/flag to add prefixes to the constants to avoid collisions that way.

WDYT?

wing328 · 2025-09-03T08:58:09Z

let me think about it ...

is it correct to say that the option RESOLVE_INLINE_ENUMS works for you but just that you want to make this option enabled by default?

sruehl · 2025-09-03T09:18:00Z

as far as I can remember I had to "bake" the option in the code like you can see in the PR as I couldn't figure another way to make it work. You can try to outcomment line 117 and let the build run.

sruehl · 2025-09-03T09:21:15Z

also looking at the changes, it seems that the "default" I set with that now enables enum Generation in other places so that is where the build failure comes from. ~~Think that is what I refer with breaking here #21623 (comment)~~

sruehl · 2025-09-04T06:58:17Z

It seem when using the option RESOLVE_INLINE_ENUMS they are getting generated.

as you mentioned, if you've the option enabled, it works fine for your use cases or still an issue with the option enabled?

yes, it helps using --inline-schema-options RESOLVE_INLINE_ENUMS=true. I adjusted the test to supply this option.

sruehl · 2025-09-04T07:02:05Z

let me think about it ...

is it correct to say that the option RESOLVE_INLINE_ENUMS works for you but just that you want to make this option enabled by default?

Not intentionally, I personally would but I have no idea what the rationale is to not have them generated. Is there a ADR or some issue for that (or a general design decision)?

So at the moment this PR is boiling down to one added test proving that the inline enums are working in general and highlighted an important issues (Think we should file one for that!?) regarding enums not being prefixed with their type name and hence producing nasty name collisions. The model_name_option you mentioned is IMHO not feasible as such collisions are expected to be quite common.

sruehl · 2025-09-04T07:13:09Z

(force-push because I could not get rid anymore of the generated code which was just not correct anymore after the latest adjustments)

wing328 · 2025-09-04T08:36:04Z

Not intentionally, I personally would but I have no idea what the rationale is to not have them generated. Is there a ADR or some issue for that (or a general design decision)?

backward compatibility

refactoring the enum into models will break those using the auto-generated Go SDK.

sruehl marked this pull request as draft July 24, 2025 09:37

sruehl marked this pull request as ready for review September 2, 2025 09:58

wing328 reviewed Sep 2, 2025

View reviewed changes

test(go): add test for RESOLVE_INLINE_ENUMS

d6ef5b1

sruehl force-pushed the fix/golang_inline_enum_generation branch from 3eb74a2 to d6ef5b1 Compare September 4, 2025 07:12

sruehl mentioned this pull request Sep 4, 2025

[BUG][GO] Enums not generated #9567

Open

6 tasks

sruehl changed the title ~~fix(go): properly generate inline enums~~ test(go): add test for RESOLVE_INLINE_ENUMS Sep 4, 2025

Uh oh!

test(go): add test for RESOLVE_INLINE_ENUMS #21623

Are you sure you want to change the base?

test(go): add test for RESOLVE_INLINE_ENUMS #21623

Conversation

sruehl commented Jul 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR checklist

Uh oh!

sruehl commented Jul 24, 2025

Uh oh!

sruehl commented Jul 24, 2025

Uh oh!

sruehl commented Sep 2, 2025

Uh oh!

sruehl commented Sep 2, 2025

Uh oh!

wing328 commented Sep 2, 2025

Uh oh!

wing328 commented Sep 2, 2025

Uh oh!

sruehl commented Sep 2, 2025

Uh oh!

wing328 commented Sep 2, 2025

Uh oh!

wing328 Sep 2, 2025

Choose a reason for hiding this comment

Uh oh!

sruehl Sep 2, 2025

Choose a reason for hiding this comment

Uh oh!

wing328 Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

sruehl Sep 4, 2025

Choose a reason for hiding this comment

Uh oh!

sruehl commented Sep 2, 2025

Uh oh!

wing328 commented Sep 3, 2025

Uh oh!

sruehl commented Sep 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wing328 commented Sep 3, 2025

Uh oh!

sruehl commented Sep 3, 2025

Uh oh!

sruehl commented Sep 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sruehl commented Sep 4, 2025

Uh oh!

sruehl commented Sep 4, 2025

Uh oh!

sruehl commented Sep 4, 2025

Uh oh!

wing328 commented Sep 4, 2025

Uh oh!

Uh oh!

sruehl commented Jul 24, 2025 •

edited

Loading

sruehl commented Sep 3, 2025 •

edited

Loading

sruehl commented Sep 3, 2025 •

edited

Loading