[C#] Emit Default is true for required properties.

[dhedey]

Partial fix for #11008. A full fix requires using nullable value types.

Details

There are two issues:

1. The handling of (non-required) value types is broken - the models can't distinguish between a value not being given, and the value being given a default value (eg 0). So either we're not spec compliant because we output 0 when we shouldn't output anything, or (as per right now) we don't output 0 at all. A proper fix for this would be to make non-required value types nullable. I propose enabling nullable value types is a separate PR as it's a breaking change.
2. The handling of required value types is broken - the handling of these is the same, and the model doesn't output 0 at all. We know for sure in this case that we should emit a zero if we have it.

This PR fixes case 2 - and sets EmitDefaultValue to true for required types (the default value for this attribute if it's not present). Note - this does lead to potentially emitting null for required non-nullable reference types - but the type is asserted to be non-null in the constructor anyway, so this shouldn't arise in practice.

Another approach would be to simply not output EmitDefaultValue at all if the field is required (which would default to emitting defaults).

A good example to see (1) and (2) is Name.cs post this fix.

NOTE: #11280 fixes 1 and 2 by making EmitDefaultValue true just for all value types; but it will cause a new issue: non-required parameters which aren't set will output 0 when they shouldn't.

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 ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  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*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (5.3.0), 6.0.x - *It appears master is now 6.0.0-SNAPSHOT` already...
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request: @mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03) @lucamazzanti (2021/05)

[hauntingEcho]

It looks like the failures here were both network issues (to maven and github) rather than test failures - could someone with access re-execute them to verify?

Node 0:

Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
[ERROR] Plugin org.jboss.jandex:jandex-maven-plugin:1.1.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.jboss.jandex:jandex-maven-plugin:jar:1.1.0: Could not transfer artifact org.jboss.jandex:jandex-maven-plugin:pom:1.1.0 from/to central (https://repo.maven.apache.org/maven2): Connection reset -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

Node 2:

PASS
ok github.com/OpenAPITools/openapi-generator/samples/openapi3/client/petstore/go	50.514s
go: downloading github.com/gorilla/mux v1.7.3
? github.com/GIT_USER_ID/GIT_REPO_ID	[no test files]
# golang.org/x/net/http2
/home/circleci/.go_workspace/src/golang.org/x/net/http2/transport.go:417:45: undefined: os.ErrDeadlineExceeded
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (go-get) on project GoGinServer: Command execution failed. Process exited with an error: 2 (Exit value: 2) -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] [ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :GoGinServer

[dhedey]

Thanks @hauntingEcho.

(@ any potential reviewers -)

In terms of anyone able to review - the key files are the mustache files, and the key context is in my original message. Happy to rebase / re-generate if/when I've got a supportive review.

More generally - I'm potentially keen / happy to help with fixing issue 1 in my original message - or creating a new variant from the ground up which would fix 1 and various other bugs I've encountered (I've worked around about 10 or so distinct issues so far) - but I'd like to discuss with someone who could review/approve first, to check any effort would be appreciated.

[dhedey]

Closing as this fix was included in #13049

[dhedey]

Partial fix for #11008. A full fix requires using nullable value types.

Details

There are two issues:

1. The handling of (non-required) value types is broken - the models can't distinguish between a value not being given, and the value being given a default value (eg 0). So either we're not spec compliant because we output 0 when we shouldn't output anything, or (as per right now) we don't output 0 at all. A proper fix for this would be to make non-required value types nullable. I propose enabling nullable value types is a separate PR as it's a breaking change.
2. The handling of required value types is broken - the handling of these is the same, and the model doesn't output 0 at all. We know for sure in this case that we should emit a zero if we have it.

This PR fixes case 2 - and sets EmitDefaultValue to true for required types (the default value for this attribute if it's not present). Note - this does lead to potentially emitting null for required non-nullable reference types - but the type is asserted to be non-null in the constructor anyway, so this shouldn't arise in practice.

Another approach would be to simply not output EmitDefaultValue at all if the field is required (which would default to emitting defaults).

A good example to see (1) and (2) is Name.cs post this fix.

NOTE: #11280 fixes 1 and 2 by making EmitDefaultValue true just for all value types; but it will cause a new issue: non-required parameters which aren't set will output 0 when they shouldn't.

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 ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  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*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (5.3.0), 6.0.x - *It appears master is now 6.0.0-SNAPSHOT` already...
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request: @mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03) @lucamazzanti (2021/05)

[hauntingEcho]

It looks like the failures here were both network issues (to maven and github) rather than test failures - could someone with access re-execute them to verify?

Node 0:

Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
[ERROR] Plugin org.jboss.jandex:jandex-maven-plugin:1.1.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.jboss.jandex:jandex-maven-plugin:jar:1.1.0: Could not transfer artifact org.jboss.jandex:jandex-maven-plugin:pom:1.1.0 from/to central (https://repo.maven.apache.org/maven2): Connection reset -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

Node 2:

PASS
ok github.com/OpenAPITools/openapi-generator/samples/openapi3/client/petstore/go	50.514s
go: downloading github.com/gorilla/mux v1.7.3
? github.com/GIT_USER_ID/GIT_REPO_ID	[no test files]
# golang.org/x/net/http2
/home/circleci/.go_workspace/src/golang.org/x/net/http2/transport.go:417:45: undefined: os.ErrDeadlineExceeded
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (go-get) on project GoGinServer: Command execution failed. Process exited with an error: 2 (Exit value: 2) -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] [ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :GoGinServer

[dhedey]

Thanks @hauntingEcho.

(@ any potential reviewers -)

In terms of anyone able to review - the key files are the mustache files, and the key context is in my original message. Happy to rebase / re-generate if/when I've got a supportive review.

More generally - I'm potentially keen / happy to help with fixing issue 1 in my original message - or creating a new variant from the ground up which would fix 1 and various other bugs I've encountered (I've worked around about 10 or so distinct issues so far) - but I'd like to discuss with someone who could review/approve first, to check any effort would be appreciated.

[dhedey]

Closing as this fix was included in #13049

[dhedey]

Partial fix for #11008. A full fix requires using nullable value types.

Details

There are two issues:

1. The handling of (non-required) value types is broken - the models can't distinguish between a value not being given, and the value being given a default value (eg 0). So either we're not spec compliant because we output 0 when we shouldn't output anything, or (as per right now) we don't output 0 at all. A proper fix for this would be to make non-required value types nullable. I propose enabling nullable value types is a separate PR as it's a breaking change.
2. The handling of required value types is broken - the handling of these is the same, and the model doesn't output 0 at all. We know for sure in this case that we should emit a zero if we have it.

This PR fixes case 2 - and sets EmitDefaultValue to true for required types (the default value for this attribute if it's not present). Note - this does lead to potentially emitting null for required non-nullable reference types - but the type is asserted to be non-null in the constructor anyway, so this shouldn't arise in practice.

Another approach would be to simply not output EmitDefaultValue at all if the field is required (which would default to emitting defaults).

A good example to see (1) and (2) is Name.cs post this fix.

NOTE: #11280 fixes 1 and 2 by making EmitDefaultValue true just for all value types; but it will cause a new issue: non-required parameters which aren't set will output 0 when they shouldn't.

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 ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  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*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (5.3.0), 6.0.x - *It appears master is now 6.0.0-SNAPSHOT` already...
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request: @mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03) @lucamazzanti (2021/05)

[hauntingEcho]

It looks like the failures here were both network issues (to maven and github) rather than test failures - could someone with access re-execute them to verify?

Node 0:

Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
[ERROR] Plugin org.jboss.jandex:jandex-maven-plugin:1.1.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.jboss.jandex:jandex-maven-plugin:jar:1.1.0: Could not transfer artifact org.jboss.jandex:jandex-maven-plugin:pom:1.1.0 from/to central (https://repo.maven.apache.org/maven2): Connection reset -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

Node 2:

PASS
ok github.com/OpenAPITools/openapi-generator/samples/openapi3/client/petstore/go	50.514s
go: downloading github.com/gorilla/mux v1.7.3
? github.com/GIT_USER_ID/GIT_REPO_ID	[no test files]
# golang.org/x/net/http2
/home/circleci/.go_workspace/src/golang.org/x/net/http2/transport.go:417:45: undefined: os.ErrDeadlineExceeded
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (go-get) on project GoGinServer: Command execution failed. Process exited with an error: 2 (Exit value: 2) -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] [ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :GoGinServer

[dhedey]

Thanks @hauntingEcho.

(@ any potential reviewers -)

In terms of anyone able to review - the key files are the mustache files, and the key context is in my original message. Happy to rebase / re-generate if/when I've got a supportive review.

More generally - I'm potentially keen / happy to help with fixing issue 1 in my original message - or creating a new variant from the ground up which would fix 1 and various other bugs I've encountered (I've worked around about 10 or so distinct issues so far) - but I'd like to discuss with someone who could review/approve first, to check any effort would be appreciated.

[dhedey]

Closing as this fix was included in #13049

[dhedey]

Partial fix for #11008. A full fix requires using nullable value types.

Details

There are two issues:

1. The handling of (non-required) value types is broken - the models can't distinguish between a value not being given, and the value being given a default value (eg 0). So either we're not spec compliant because we output 0 when we shouldn't output anything, or (as per right now) we don't output 0 at all. A proper fix for this would be to make non-required value types nullable. I propose enabling nullable value types is a separate PR as it's a breaking change.
2. The handling of required value types is broken - the handling of these is the same, and the model doesn't output 0 at all. We know for sure in this case that we should emit a zero if we have it.

This PR fixes case 2 - and sets EmitDefaultValue to true for required types (the default value for this attribute if it's not present). Note - this does lead to potentially emitting null for required non-nullable reference types - but the type is asserted to be non-null in the constructor anyway, so this shouldn't arise in practice.

Another approach would be to simply not output EmitDefaultValue at all if the field is required (which would default to emitting defaults).

A good example to see (1) and (2) is Name.cs post this fix.

NOTE: #11280 fixes 1 and 2 by making EmitDefaultValue true just for all value types; but it will cause a new issue: non-required parameters which aren't set will output 0 when they shouldn't.

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 ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  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*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (5.3.0), 6.0.x - *It appears master is now 6.0.0-SNAPSHOT` already...
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request: @mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03) @lucamazzanti (2021/05)

[hauntingEcho]

It looks like the failures here were both network issues (to maven and github) rather than test failures - could someone with access re-execute them to verify?

Node 0:

Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
[ERROR] Plugin org.jboss.jandex:jandex-maven-plugin:1.1.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.jboss.jandex:jandex-maven-plugin:jar:1.1.0: Could not transfer artifact org.jboss.jandex:jandex-maven-plugin:pom:1.1.0 from/to central (https://repo.maven.apache.org/maven2): Connection reset -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

Node 2:

PASS
ok github.com/OpenAPITools/openapi-generator/samples/openapi3/client/petstore/go	50.514s
go: downloading github.com/gorilla/mux v1.7.3
? github.com/GIT_USER_ID/GIT_REPO_ID	[no test files]
# golang.org/x/net/http2
/home/circleci/.go_workspace/src/golang.org/x/net/http2/transport.go:417:45: undefined: os.ErrDeadlineExceeded
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (go-get) on project GoGinServer: Command execution failed. Process exited with an error: 2 (Exit value: 2) -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] [ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :GoGinServer

[dhedey]

Thanks @hauntingEcho.

(@ any potential reviewers -)

In terms of anyone able to review - the key files are the mustache files, and the key context is in my original message. Happy to rebase / re-generate if/when I've got a supportive review.

More generally - I'm potentially keen / happy to help with fixing issue 1 in my original message - or creating a new variant from the ground up which would fix 1 and various other bugs I've encountered (I've worked around about 10 or so distinct issues so far) - but I'd like to discuss with someone who could review/approve first, to check any effort would be appreciated.

[dhedey]

Closing as this fix was included in #13049

[dhedey]

Partial fix for #11008. A full fix requires using nullable value types.

Details

There are two issues:

1. The handling of (non-required) value types is broken - the models can't distinguish between a value not being given, and the value being given a default value (eg 0). So either we're not spec compliant because we output 0 when we shouldn't output anything, or (as per right now) we don't output 0 at all. A proper fix for this would be to make non-required value types nullable. I propose enabling nullable value types is a separate PR as it's a breaking change.
2. The handling of required value types is broken - the handling of these is the same, and the model doesn't output 0 at all. We know for sure in this case that we should emit a zero if we have it.

This PR fixes case 2 - and sets EmitDefaultValue to true for required types (the default value for this attribute if it's not present). Note - this does lead to potentially emitting null for required non-nullable reference types - but the type is asserted to be non-null in the constructor anyway, so this shouldn't arise in practice.

Another approach would be to simply not output EmitDefaultValue at all if the field is required (which would default to emitting defaults).

A good example to see (1) and (2) is Name.cs post this fix.

NOTE: #11280 fixes 1 and 2 by making EmitDefaultValue true just for all value types; but it will cause a new issue: non-required parameters which aren't set will output 0 when they shouldn't.

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 ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  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*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (5.3.0), 6.0.x - *It appears master is now 6.0.0-SNAPSHOT` already...
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request: @mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03) @lucamazzanti (2021/05)

[hauntingEcho]

It looks like the failures here were both network issues (to maven and github) rather than test failures - could someone with access re-execute them to verify?

Node 0:

Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
[ERROR] Plugin org.jboss.jandex:jandex-maven-plugin:1.1.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.jboss.jandex:jandex-maven-plugin:jar:1.1.0: Could not transfer artifact org.jboss.jandex:jandex-maven-plugin:pom:1.1.0 from/to central (https://repo.maven.apache.org/maven2): Connection reset -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

Node 2:

PASS
ok github.com/OpenAPITools/openapi-generator/samples/openapi3/client/petstore/go	50.514s
go: downloading github.com/gorilla/mux v1.7.3
? github.com/GIT_USER_ID/GIT_REPO_ID	[no test files]
# golang.org/x/net/http2
/home/circleci/.go_workspace/src/golang.org/x/net/http2/transport.go:417:45: undefined: os.ErrDeadlineExceeded
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (go-get) on project GoGinServer: Command execution failed. Process exited with an error: 2 (Exit value: 2) -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] [ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :GoGinServer

[dhedey]

Thanks @hauntingEcho.

(@ any potential reviewers -)

In terms of anyone able to review - the key files are the mustache files, and the key context is in my original message. Happy to rebase / re-generate if/when I've got a supportive review.

More generally - I'm potentially keen / happy to help with fixing issue 1 in my original message - or creating a new variant from the ground up which would fix 1 and various other bugs I've encountered (I've worked around about 10 or so distinct issues so far) - but I'd like to discuss with someone who could review/approve first, to check any effort would be appreciated.

[dhedey]

Closing as this fix was included in #13049

[dhedey]

Partial fix for #11008. A full fix requires using nullable value types.

Details

There are two issues:

1. The handling of (non-required) value types is broken - the models can't distinguish between a value not being given, and the value being given a default value (eg 0). So either we're not spec compliant because we output 0 when we shouldn't output anything, or (as per right now) we don't output 0 at all. A proper fix for this would be to make non-required value types nullable. I propose enabling nullable value types is a separate PR as it's a breaking change.
2. The handling of required value types is broken - the handling of these is the same, and the model doesn't output 0 at all. We know for sure in this case that we should emit a zero if we have it.

This PR fixes case 2 - and sets EmitDefaultValue to true for required types (the default value for this attribute if it's not present). Note - this does lead to potentially emitting null for required non-nullable reference types - but the type is asserted to be non-null in the constructor anyway, so this shouldn't arise in practice.

Another approach would be to simply not output EmitDefaultValue at all if the field is required (which would default to emitting defaults).

A good example to see (1) and (2) is Name.cs post this fix.

NOTE: #11280 fixes 1 and 2 by making EmitDefaultValue true just for all value types; but it will cause a new issue: non-required parameters which aren't set will output 0 when they shouldn't.

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 ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  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*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (5.3.0), 6.0.x - *It appears master is now 6.0.0-SNAPSHOT` already...
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request: @mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03) @lucamazzanti (2021/05)

[hauntingEcho]

It looks like the failures here were both network issues (to maven and github) rather than test failures - could someone with access re-execute them to verify?

Node 0:

Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
[ERROR] Plugin org.jboss.jandex:jandex-maven-plugin:1.1.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.jboss.jandex:jandex-maven-plugin:jar:1.1.0: Could not transfer artifact org.jboss.jandex:jandex-maven-plugin:pom:1.1.0 from/to central (https://repo.maven.apache.org/maven2): Connection reset -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

Node 2:

PASS
ok github.com/OpenAPITools/openapi-generator/samples/openapi3/client/petstore/go	50.514s
go: downloading github.com/gorilla/mux v1.7.3
? github.com/GIT_USER_ID/GIT_REPO_ID	[no test files]
# golang.org/x/net/http2
/home/circleci/.go_workspace/src/golang.org/x/net/http2/transport.go:417:45: undefined: os.ErrDeadlineExceeded
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (go-get) on project GoGinServer: Command execution failed. Process exited with an error: 2 (Exit value: 2) -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] [ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :GoGinServer

[dhedey]

Thanks @hauntingEcho.

(@ any potential reviewers -)

In terms of anyone able to review - the key files are the mustache files, and the key context is in my original message. Happy to rebase / re-generate if/when I've got a supportive review.

More generally - I'm potentially keen / happy to help with fixing issue 1 in my original message - or creating a new variant from the ground up which would fix 1 and various other bugs I've encountered (I've worked around about 10 or so distinct issues so far) - but I'd like to discuss with someone who could review/approve first, to check any effort would be appreciated.

[dhedey]

Closing as this fix was included in #13049

[dhedey]

Partial fix for #11008. A full fix requires using nullable value types.

Details

There are two issues:

1. The handling of (non-required) value types is broken - the models can't distinguish between a value not being given, and the value being given a default value (eg 0). So either we're not spec compliant because we output 0 when we shouldn't output anything, or (as per right now) we don't output 0 at all. A proper fix for this would be to make non-required value types nullable. I propose enabling nullable value types is a separate PR as it's a breaking change.
2. The handling of required value types is broken - the handling of these is the same, and the model doesn't output 0 at all. We know for sure in this case that we should emit a zero if we have it.

This PR fixes case 2 - and sets EmitDefaultValue to true for required types (the default value for this attribute if it's not present). Note - this does lead to potentially emitting null for required non-nullable reference types - but the type is asserted to be non-null in the constructor anyway, so this shouldn't arise in practice.

Another approach would be to simply not output EmitDefaultValue at all if the field is required (which would default to emitting defaults).

A good example to see (1) and (2) is Name.cs post this fix.

NOTE: #11280 fixes 1 and 2 by making EmitDefaultValue true just for all value types; but it will cause a new issue: non-required parameters which aren't set will output 0 when they shouldn't.

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 ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  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*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (5.3.0), 6.0.x - *It appears master is now 6.0.0-SNAPSHOT` already...
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request: @mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03) @lucamazzanti (2021/05)

[hauntingEcho]

It looks like the failures here were both network issues (to maven and github) rather than test failures - could someone with access re-execute them to verify?

Node 0:

Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
[ERROR] Plugin org.jboss.jandex:jandex-maven-plugin:1.1.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.jboss.jandex:jandex-maven-plugin:jar:1.1.0: Could not transfer artifact org.jboss.jandex:jandex-maven-plugin:pom:1.1.0 from/to central (https://repo.maven.apache.org/maven2): Connection reset -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

Node 2:

PASS
ok github.com/OpenAPITools/openapi-generator/samples/openapi3/client/petstore/go	50.514s
go: downloading github.com/gorilla/mux v1.7.3
? github.com/GIT_USER_ID/GIT_REPO_ID	[no test files]
# golang.org/x/net/http2
/home/circleci/.go_workspace/src/golang.org/x/net/http2/transport.go:417:45: undefined: os.ErrDeadlineExceeded
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (go-get) on project GoGinServer: Command execution failed. Process exited with an error: 2 (Exit value: 2) -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] [ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :GoGinServer

[dhedey]

Thanks @hauntingEcho.

(@ any potential reviewers -)

In terms of anyone able to review - the key files are the mustache files, and the key context is in my original message. Happy to rebase / re-generate if/when I've got a supportive review.

More generally - I'm potentially keen / happy to help with fixing issue 1 in my original message - or creating a new variant from the ground up which would fix 1 and various other bugs I've encountered (I've worked around about 10 or so distinct issues so far) - but I'd like to discuss with someone who could review/approve first, to check any effort would be appreciated.

[dhedey]

Closing as this fix was included in #13049

[dhedey]

Partial fix for #11008. A full fix requires using nullable value types.

Details

There are two issues:

1. The handling of (non-required) value types is broken - the models can't distinguish between a value not being given, and the value being given a default value (eg 0). So either we're not spec compliant because we output 0 when we shouldn't output anything, or (as per right now) we don't output 0 at all. A proper fix for this would be to make non-required value types nullable. I propose enabling nullable value types is a separate PR as it's a breaking change.
2. The handling of required value types is broken - the handling of these is the same, and the model doesn't output 0 at all. We know for sure in this case that we should emit a zero if we have it.

This PR fixes case 2 - and sets EmitDefaultValue to true for required types (the default value for this attribute if it's not present). Note - this does lead to potentially emitting null for required non-nullable reference types - but the type is asserted to be non-null in the constructor anyway, so this shouldn't arise in practice.

Another approach would be to simply not output EmitDefaultValue at all if the field is required (which would default to emitting defaults).

A good example to see (1) and (2) is Name.cs post this fix.

NOTE: #11280 fixes 1 and 2 by making EmitDefaultValue true just for all value types; but it will cause a new issue: non-required parameters which aren't set will output 0 when they shouldn't.

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 ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  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*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (5.3.0), 6.0.x - *It appears master is now 6.0.0-SNAPSHOT` already...
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request: @mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03) @lucamazzanti (2021/05)

[hauntingEcho]

It looks like the failures here were both network issues (to maven and github) rather than test failures - could someone with access re-execute them to verify?

Node 0:

Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Feb 14, 2022 5:57:01 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443
[ERROR] Plugin org.jboss.jandex:jandex-maven-plugin:1.1.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.jboss.jandex:jandex-maven-plugin:jar:1.1.0: Could not transfer artifact org.jboss.jandex:jandex-maven-plugin:pom:1.1.0 from/to central (https://repo.maven.apache.org/maven2): Connection reset -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

Node 2:

PASS
ok github.com/OpenAPITools/openapi-generator/samples/openapi3/client/petstore/go	50.514s
go: downloading github.com/gorilla/mux v1.7.3
? github.com/GIT_USER_ID/GIT_REPO_ID	[no test files]
# golang.org/x/net/http2
/home/circleci/.go_workspace/src/golang.org/x/net/http2/transport.go:417:45: undefined: os.ErrDeadlineExceeded
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (go-get) on project GoGinServer: Command execution failed. Process exited with an error: 2 (Exit value: 2) -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] [ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :GoGinServer

[dhedey]

Thanks @hauntingEcho.

(@ any potential reviewers -)

In terms of anyone able to review - the key files are the mustache files, and the key context is in my original message. Happy to rebase / re-generate if/when I've got a supportive review.

More generally - I'm potentially keen / happy to help with fixing issue 1 in my original message - or creating a new variant from the ground up which would fix 1 and various other bugs I've encountered (I've worked around about 10 or so distinct issues so far) - but I'd like to discuss with someone who could review/approve first, to check any effort would be appreciated.

[dhedey]

Closing as this fix was included in #13049