[Java] [Spring] mixed OneOf support with inheritance and JsonUnwrapped

[jpfinne]

Fix OpenAPITools#23759

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 solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[cubic-dev-ai]

20 issues found across 71 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="samples/client/petstore/typescript-fetch/builds/oneOf/docs/DefaultApi.md">

<violation number="1" location="samples/client/petstore/typescript-fetch/builds/oneOf/docs/DefaultApi.md:142">
P3: The two new usage examples import request types that the generated client does not contain, so copying either example produces a missing-export TypeScript error (and an unused import). Since these parameterless operations never use request objects, omit both `*Request` imports from the generated documentation.</violation>
</file>

<file name="samples/client/petstore/typescript-fetch/builds/oneOf/models/TestDashedDiscriminatorResponse.ts">

<violation number="1" location="samples/client/petstore/typescript-fetch/builds/oneOf/models/TestDashedDiscriminatorResponse.ts:17">
P3: The generated model carries four unused value imports, adding noise and potentially retaining unnecessary runtime module bindings under configurations that preserve value imports. Consider updating the generator template to emit only the `FromJSONTyped` and `ToJSON` helpers used by this oneOf serializer.</violation>
</file>

<file name="samples/client/petstore/typescript-fetch/builds/oneOf/docs/DashedOptionTwo.md">

<violation number="1" location="samples/client/petstore/typescript-fetch/builds/oneOf/docs/DashedOptionTwo.md:15">
P2: The new example cannot be compiled or copied because its type import uses an empty module specifier. Consider configuring `npmName` for this sample or generating a valid relative import when `npmName` is absent.</violation>
</file>

<file name="samples/client/petstore/typescript-fetch/builds/oneOf/docs/TestSnakeCaseDiscriminatorResponse.md">

<violation number="1" location="samples/client/petstore/typescript-fetch/builds/oneOf/docs/TestSnakeCaseDiscriminatorResponse.md:19">
P2: The example fails its own `satisfies TestSnakeCaseDiscriminatorResponse` check because `null` is neither a valid discriminator literal nor a string property value. Use one complete valid union variant so readers can compile and run the example.</violation>
</file>

<file name="samples/client/petstore/typescript-fetch/builds/default-v3.0/models/EnumTest.ts">

<violation number="1" location="samples/client/petstore/typescript-fetch/builds/default-v3.0/models/EnumTest.ts:145">
P2: Raw JSON objects containing only `enum_string_required` now pass this type guard even though they do not implement `EnumTest`, so callers are incorrectly narrowed and can read the required `enumStringRequired` as `undefined`. If raw wire-format detection is needed, it should use a separate predicate/type or convert the object before claiming `value is EnumTest`.</violation>
</file>

<file name="samples/client/petstore/typescript-fetch/builds/oneOf/docs/DashedOptionOne.md">

<violation number="1" location="samples/client/petstore/typescript-fetch/builds/oneOf/docs/DashedOptionOne.md:26">
P2: This round-trip produces camelCase JSON instead of the schema's dashed wire fields, then merely asserts the dashed-key object as `DashedOptionOne`. The example should serialize with `DashedOptionOneToJSON` and parse with `DashedOptionOneFromJSON`, importing both helpers.</violation>
</file>

<file name="samples/client/petstore/typescript-fetch/builds/oneOf/models/SnakeOptionOne.ts">

<violation number="1" location="samples/client/petstore/typescript-fetch/builds/oneOf/models/SnakeOptionOne.ts:15">
P3: This generated model adds an unused runtime import, leaving dead generated code and potentially loading `../runtime` solely for an unused binding. Consider omitting `mapValues` from the generating template when a model has no mapped collection properties.</violation>
</file>

<file name="samples/client/petstore/typescript-fetch/builds/oneOf/models/DashedOptionOne.ts">

<violation number="1" location="samples/client/petstore/typescript-fetch/builds/oneOf/models/DashedOptionOne.ts:72">
P2: The public return type promises a model object, but the function returns a wire-format object with dashed keys; callers can therefore access supposedly present camel-case fields and receive `undefined`. Match `DashedOptionOneToJSONTyped` by returning `any` (or a dedicated wire type).</violation>
</file>

<file name="modules/openapi-generator/src/main/resources/csharp/HttpSigningConfiguration.mustache">

<violation number="1" location="modules/openapi-generator/src/main/resources/csharp/HttpSigningConfiguration.mustache:28">
P1: HTTP-signature clients targeting the supported `net47` framework no longer compile: the constructor references `RuntimeInformation`, which is unavailable in the .NET Framework 4.7 reference assemblies. Guarding this initialization with `NETCOREAPP` preserves the new behavior where it is used without breaking `net47` generation.</violation>
</file>

<file name="samples/client/petstore/typescript-fetch/builds/oneOf/docs/NumericSingletonEnumModel.md">

<violation number="1" location="samples/client/petstore/typescript-fetch/builds/oneOf/docs/NumericSingletonEnumModel.md:9">
P3: The property documentation omits the defining singleton-enum constraint, so readers are led to believe any number is accepted although the generated model only permits `42`. Consider exposing the enum type or its sole allowed value in this table.</violation>
</file>

<file name="samples/client/petstore/csharp/unityWebRequest/net9/Petstore/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs">

<violation number="1" location="samples/client/petstore/csharp/unityWebRequest/net9/Petstore/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs:82">
P3: This generated client uses UnityWebRequest, so the RestSharp-specific explanation points maintainers to the wrong transport. Transport-neutral wording would keep the shared signing behavior accurate here.</violation>
</file>

<file name="samples/client/petstore/csharp/restsharp/standard2.0/Petstore/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs">

<violation number="1" location="samples/client/petstore/csharp/restsharp/standard2.0/Petstore/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs:80">
P3: This comment attributes key encoding to `ParseQueryString`, although encoding actually occurs when the returned collection is serialized. Describing that lifecycle would keep the version-dependent workaround understandable and avoid misleading future changes.</violation>

<violation number="2" location="samples/client/petstore/csharp/restsharp/standard2.0/Petstore/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs:154">
P1: Special-character query keys still produce an incorrect signed request target for this netstandard2.0 client on .NET 8 and earlier because the new encoding is compiled only in the `NETCOREAPP` branch. Including `NETSTANDARD` in this branch or sharing the key handling across both branches would make the fix effective for this generated sample.</violation>
</file>

<file name="modules/openapi-generator/src/main/resources/typescript-fetch/modelGeneric.mustache">

<violation number="1" location="modules/openapi-generator/src/main/resources/typescript-fetch/modelGeneric.mustache:34">
P2: The new singleton-enum check in `instanceOf` runs for every required single-value enum property, without a nullable guard. In this codebase, required fields can legitimately be nullable (`{{#isNullable}}` is generated for both fromJSON and ToJSON), so a required nullable singleton-enum property whose payload value is `null` will now fail `instanceOf` (presence passes because `null !== undefined`, but `value['kind'] !== 42` is true for `null`). That can cause valid objects to be rejected by oneOf dispatch and by generated validation. Consider guarding the enum-value comparison with `{{#isNullable}}` so that `null` is only rejected when the field is not nullable, or otherwise confirming the intended behavior for nullable singleton enums.</violation>

<violation number="2" location="modules/openapi-generator/src/main/resources/typescript-fetch/modelGeneric.mustache:38">
P1: OneOf branches with multi-value enum tags can still deserialize as the first structurally matching model because these guards emit no value check unless the enum is a singleton. The generated guard should test membership against every allowed enum value.</violation>

<violation number="3" location="modules/openapi-generator/src/main/resources/typescript-fetch/modelGeneric.mustache:40">
P2: Objects containing both wire and sanitized property names can be classified into the wrong OneOf branch when only the sanitized alias has the expected enum value; conversion then consumes the conflicting wire value. The guard should prioritize `baseName` when it is present, otherwise check `name`, rather than accepting either comparison.</violation>

<violation number="4" location="modules/openapi-generator/src/main/resources/typescript-fetch/modelGeneric.mustache:44">
P2: Singleton string enum values containing apostrophes or other escaped characters can produce invalid or incorrect generated TypeScript because `{{.}}` is inserted as an unescaped source literal. Iterating `enumVars` and using its pre-escaped `value` would preserve valid enum literals.</violation>
</file>

<file name="samples/client/petstore/csharp/unityWebRequest/net10/Petstore/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs">

<violation number="1" location="samples/client/petstore/csharp/unityWebRequest/net10/Petstore/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs:154">
P1: HTTP-signed UnityWebRequest calls with special query keys such as `$filter` can be rejected because the signed request-target and outgoing URI use different key encoding. This should derive the signature target from the same finalized URI/query builder used by `WebRequestPathBuilder`, rather than applying the RestSharp-specific encoding branch in this Unity client.</violation>
</file>

<file name="samples/client/petstore/csharp/restsharp/net9/EnumMappings/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs">

<violation number="1" location="samples/client/petstore/csharp/restsharp/net9/EnumMappings/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs:36">
P3: Query signing can silently fall back to double-encoding if the display-oriented `FrameworkDescription` format changes, because `_skipUrlEncode` parses that string. Using `Environment.Version.Major` behind an ordinal `.NET ` runtime guard avoids this fragile parsing.</violation>
</file>

<file name="modules/openapi-generator/src/main/resources/kotlin-client/libraries/multiplatform/infrastructure/ApiClient.kt.mustache">

<violation number="1" location="modules/openapi-generator/src/main/resources/kotlin-client/libraries/multiplatform/infrastructure/ApiClient.kt.mustache:169">
P2: This adds DELETE to the body-handling branch, so every DELETE request now sets Content-Type: application/json and calls setBody(body) even when there is no request body (body == null). For the common bodyless DELETE case this means the client now advertises a JSON content type where it previously sent none. Some servers treat a Content-Type on a bodyless DELETE differently (e.g. rejecting/415 on requests that shouldn't carry a body), so this is a client behavior change beyond the intended 'support DELETE request bodies' goal. Consider only setting the content type and body when a body is actually present, or scope the header emission to requests that carry a body, to keep bodyless DELETE requests unchanged while still enabling DELETEs that send a body.</violation>
</file>

<sub>Tip: instead of fixing issues one by one fix them all with cubic

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: HTTP-signature clients targeting the supported net47 framework no longer compile: the constructor references RuntimeInformation, which is unavailable in the .NET Framework 4.7 reference assemblies. Guarding this initialization with NETCOREAPP preserves the new behavior where it is used without breaking net47 generation.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/resources/csharp/HttpSigningConfiguration.mustache, line 28:

<comment>HTTP-signature clients targeting the supported `net47` framework no longer compile: the constructor references `RuntimeInformation`, which is unavailable in the .NET Framework 4.7 reference assemblies. Guarding this initialization with `NETCOREAPP` preserves the new behavior where it is used without breaking `net47` generation.</comment>

<file context>
@@ -25,6 +25,8 @@ namespace {{packageName}}.Client
         {
             HashAlgorithm = HashAlgorithmName.SHA256;
             SigningAlgorithm = "PKCS1-v15";
+            _skipUrlEncode = RuntimeInformation.FrameworkDescription.StartsWith(".NET ") &&
+                int.TryParse(RuntimeInformation.FrameworkDescription.Substring(5).Split('.')[0], out int fwMajor) && fwMajor >= 9;
         }
</file context>

Suggested change

	_skipUrlEncode = RuntimeInformation.FrameworkDescription.StartsWith(".NET ") &&
	int.TryParse(RuntimeInformation.FrameworkDescription.Substring(5).Split('.')[0], out int fwMajor) && fwMajor >= 9;
	#if (NETCOREAPP)
	_skipUrlEncode = RuntimeInformation.FrameworkDescription.StartsWith(".NET ") &&
	int.TryParse(RuntimeInformation.FrameworkDescription.Substring(5).Split('.')[0], out int fwMajor) && fwMajor >= 9;
	#endif

[cubic-dev-ai]

P1: Special-character query keys still produce an incorrect signed request target for this netstandard2.0 client on .NET 8 and earlier because the new encoding is compiled only in the NETCOREAPP branch. Including NETSTANDARD in this branch or sharing the key handling across both branches would make the fix effective for this generated sample.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At samples/client/petstore/csharp/restsharp/standard2.0/Petstore/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs, line 154:

<comment>Special-character query keys still produce an incorrect signed request target for this netstandard2.0 client on .NET 8 and earlier because the new encoding is compiled only in the `NETCOREAPP` branch. Including `NETSTANDARD` in this branch or sharing the key handling across both branches would make the fix effective for this generated sample.</comment>

<file context>
@@ -141,8 +151,7 @@ public Dictionary<string, string> GetHttpSignedHeader(string basePath,string met
 #if (NETCOREAPP)
-                string framework = RuntimeInformation.FrameworkDescription;
-                string key = framework.StartsWith(".NET 9") ? parameter.Key : parameter.Key;
+                string key = _skipUrlEncode ? parameter.Key : HttpUtility.UrlEncode(parameter.Key);
                 if (parameter.Value.Count > 1)
                 { // array
</file context>

[cubic-dev-ai]

P1: OneOf branches with multi-value enum tags can still deserialize as the first structurally matching model because these guards emit no value check unless the enum is a singleton. The generated guard should test membership against every allowed enum value.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/resources/typescript-fetch/modelGeneric.mustache, line 38:

<comment>OneOf branches with multi-value enum tags can still deserialize as the first structurally matching model because these guards emit no value check unless the enum is a singleton. The generated guard should test membership against every allowed enum value.</comment>

<file context>
@@ -25,7 +25,30 @@ import { type {{modelName}}, {{modelName}}FromJSONTyped, {{modelName}}ToJSON, {{
+    {{#allowableValues}}
+    {{#values}}
+    {{#-first}}
+    {{#-last}}
+    {{#hasSanitizedName}}
+    {{#isString}}if (value['{{name}}'] !== '{{.}}' && value['{{baseName}}'] !== '{{.}}') return false;{{/isString}}
</file context>

[cubic-dev-ai]

P1: HTTP-signed UnityWebRequest calls with special query keys such as $filter can be rejected because the signed request-target and outgoing URI use different key encoding. This should derive the signature target from the same finalized URI/query builder used by WebRequestPathBuilder, rather than applying the RestSharp-specific encoding branch in this Unity client.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At samples/client/petstore/csharp/unityWebRequest/net10/Petstore/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs, line 154:

<comment>HTTP-signed UnityWebRequest calls with special query keys such as `$filter` can be rejected because the signed request-target and outgoing URI use different key encoding. This should derive the signature target from the same finalized URI/query builder used by `WebRequestPathBuilder`, rather than applying the RestSharp-specific encoding branch in this Unity client.</comment>

<file context>
@@ -141,8 +151,7 @@ public Dictionary<string, string> GetHttpSignedHeader(string basePath,string met
 #if (NETCOREAPP)
-                string framework = RuntimeInformation.FrameworkDescription;
-                string key = framework.StartsWith(".NET 9") ? parameter.Key : HttpUtility.UrlEncode(parameter.Key);
+                string key = _skipUrlEncode ? parameter.Key : HttpUtility.UrlEncode(parameter.Key);
                 if (parameter.Value.Count > 1)
                 { // array
</file context>

[cubic-dev-ai]

P2: The new example cannot be compiled or copied because its type import uses an empty module specifier. Consider configuring npmName for this sample or generating a valid relative import when npmName is absent.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At samples/client/petstore/typescript-fetch/builds/oneOf/docs/DashedOptionTwo.md, line 15:

<comment>The new example cannot be compiled or copied because its type import uses an empty module specifier. Consider configuring `npmName` for this sample or generating a valid relative import when `npmName` is absent.</comment>

<file context>
@@ -0,0 +1,36 @@
+## Example
+
+```typescript
+import type { DashedOptionTwo } from ''
+
+// TODO: Update the object below with actual values
</file context>

[cubic-dev-ai]

P3: This generated model adds an unused runtime import, leaving dead generated code and potentially loading ../runtime solely for an unused binding. Consider omitting mapValues from the generating template when a model has no mapped collection properties.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At samples/client/petstore/typescript-fetch/builds/oneOf/models/SnakeOptionOne.ts, line 15:

<comment>This generated model adds an unused runtime import, leaving dead generated code and potentially loading `../runtime` solely for an unused binding. Consider omitting `mapValues` from the generating template when a model has no mapped collection properties.</comment>

<file context>
@@ -0,0 +1,87 @@
+ * Do not edit the class manually.
+ */
+
+import { mapValues } from '../runtime';
+/**
+ * 
</file context>

[cubic-dev-ai]

P3: The property documentation omits the defining singleton-enum constraint, so readers are led to believe any number is accepted although the generated model only permits 42. Consider exposing the enum type or its sole allowed value in this table.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At samples/client/petstore/typescript-fetch/builds/oneOf/docs/NumericSingletonEnumModel.md, line 9:

<comment>The property documentation omits the defining singleton-enum constraint, so readers are led to believe any number is accepted although the generated model only permits `42`. Consider exposing the enum type or its sole allowed value in this table.</comment>

<file context>
@@ -0,0 +1,34 @@
+
+Name | Type
+------------ | -------------
+`kind` | number
+
+## Example
</file context>

[cubic-dev-ai]

P3: This generated client uses UnityWebRequest, so the RestSharp-specific explanation points maintainers to the wrong transport. Transport-neutral wording would keep the shared signing behavior accurate here.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At samples/client/petstore/csharp/unityWebRequest/net9/Petstore/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs, line 82:

<comment>This generated client uses UnityWebRequest, so the RestSharp-specific explanation points maintainers to the wrong transport. Transport-neutral wording would keep the shared signing behavior accurate here.</comment>

<file context>
@@ -75,6 +77,14 @@ public HttpSigningConfiguration()
 
+        // On .NET 9+, HttpUtility.ParseQueryString already URL-encodes keys internally,
+        // so calling UrlEncode again would cause double-encoding and produce a signature
+        // that does not match the actual request sent by RestSharp 112+.
+        // On .NET 8 and earlier, keys must be explicitly URL-encoded so that special
+        // characters (e.g. '$' in OData params like $filter) are encoded the same way
</file context>

Suggested change

	// that does not match the actual request sent by RestSharp 112+.
	// that does not match the actual outgoing request.

[cubic-dev-ai]

P3: This comment attributes key encoding to ParseQueryString, although encoding actually occurs when the returned collection is serialized. Describing that lifecycle would keep the version-dependent workaround understandable and avoid misleading future changes.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At samples/client/petstore/csharp/restsharp/standard2.0/Petstore/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs, line 80:

<comment>This comment attributes key encoding to `ParseQueryString`, although encoding actually occurs when the returned collection is serialized. Describing that lifecycle would keep the version-dependent workaround understandable and avoid misleading future changes.</comment>

<file context>
@@ -75,6 +77,14 @@ public HttpSigningConfiguration()
         /// </summary>
         public int SignatureValidityPeriod { get; set; }
 
+        // On .NET 9+, HttpUtility.ParseQueryString already URL-encodes keys internally,
+        // so calling UrlEncode again would cause double-encoding and produce a signature
+        // that does not match the actual request sent by RestSharp 112+.
</file context>

Suggested change

	// On .NET 9+, HttpUtility.ParseQueryString already URL-encodes keys internally,
	// so calling UrlEncode again would cause double-encoding and produce a signature
	// On .NET 9+, the collection returned by HttpUtility.ParseQueryString URL-encodes
	// keys when serialized, so pre-encoding them would produce a double-encoded signature

[cubic-dev-ai]

P3: Query signing can silently fall back to double-encoding if the display-oriented FrameworkDescription format changes, because _skipUrlEncode parses that string. Using Environment.Version.Major behind an ordinal .NET runtime guard avoids this fragile parsing.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At samples/client/petstore/csharp/restsharp/net9/EnumMappings/src/Org.OpenAPITools/Client/HttpSigningConfiguration.cs, line 36:

<comment>Query signing can silently fall back to double-encoding if the display-oriented `FrameworkDescription` format changes, because `_skipUrlEncode` parses that string. Using `Environment.Version.Major` behind an ordinal `.NET ` runtime guard avoids this fragile parsing.</comment>

<file context>
@@ -33,6 +33,8 @@ public HttpSigningConfiguration()
         {
             HashAlgorithm = HashAlgorithmName.SHA256;
             SigningAlgorithm = "PKCS1-v15";
+            _skipUrlEncode = RuntimeInformation.FrameworkDescription.StartsWith(".NET ") &&
+                int.TryParse(RuntimeInformation.FrameworkDescription.Substring(5).Split('.')[0], out int fwMajor) && fwMajor >= 9;
         }
</file context>

Suggested change

	_skipUrlEncode = RuntimeInformation.FrameworkDescription.StartsWith(".NET ") &&
	int.TryParse(RuntimeInformation.FrameworkDescription.Substring(5).Split('.')[0], out int fwMajor) && fwMajor >= 9;
	_skipUrlEncode = RuntimeInformation.FrameworkDescription.StartsWith(".NET ", StringComparison.Ordinal) &&
	Environment.Version.Major >= 9;