[core] Keep explicit inlineSchemaNameMappings when several inline schemas map to one name

[mohitduhan19]

Fixes #25179

Since 7.26.0, when several inlineSchemaNameMappings entries map different inline schemas onto the same name (e.g. Preview_balance=Money,Preview_interest=Money), only the first one gets that name and the others become Money1, Money2, ... In 7.25.0 all of them used the mapped model.

The cause is the collision re-check added to InlineModelResolver.addSchemas in #24760. It runs after the mapping lookup, so it also renames a name the user chose explicitly. This change applies the re-check only to generated names. A mapped name is used as is, which restores the 7.25.0 behaviour for explicit mappings and keeps the #24760 protection for generated names during recursive flattening.

Tests: added testInlineSchemaNameMappingManyToOne to InlineModelResolverTest with the spec from the issue (two inline objects that differ only in description, both mapped to Money). It fails on master and passes with this change: both properties reference Money and no Money1 is created. All 62 InlineModelResolverTest tests pass, and the full openapi-generator module test suite passes (5327 tests) apart from one Go test that needs network access to download a Go module.

PR checklist

Read the contribution guidelines. Built the project and checked the sample configs: none of bin/configs/*.yaml use inlineSchemaNameMappings, so no samples change.

cc @wing328

---

Summary by cubic

Fixes a regression where multiple inlineSchemaNameMappings entries mapping to the same name (e.g., Preview_balance=Money and Preview_interest=Money) renamed all but the first to Money_1, Money_2, etc., instead of keeping the mapped name.

• The collision re-check now applies only to generated names, not explicit mappings.
• Restores the 7.25.0 behavior for explicit mappings while retaining collision protection for recursive flattening.
• Warns when a mapped name already exists in the spec, then replaces the existing schema in place.
• Adds a test with the issue's spec verifying both properties reference Money and no Money_1 is created.

^{Written for commit a3bcbe1. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 3 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="modules/openapi-generator/src/main/java/org/openapitools/codegen/InlineModelResolver.java">

<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/InlineModelResolver.java:1187">
P2: Mapped names now bypass the `components.schemas.containsKey(name)` check entirely, so a mapped value that collides with an existing spec-defined schema silently overwrites it. `addSchemas` unconditionally calls `openAPI.getComponents().addSchemas(name, schema)` (a map put) afterward, so e.g. `inlineSchemaNameMapping: {Preview_balance: Money}` with a pre-existing `components.schemas.Money` replaces the original `Money` definition and rebinds every existing `$ref: '#/components/schemas/Money'` to the inline schema. Guard the overwrite: only allow the explicit name to win when the existing entry was itself created by an earlier mapping, otherwise fall back to `uniqueName(name)` (or at least emit a warning before overwriting).</violation>
</file>

<sub>Reply to a comment to ask cubic a question or push back. It learns from your replies.

View guided diff | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: Mapped names now bypass the components.schemas.containsKey(name) check entirely, so a mapped value that collides with an existing spec-defined schema silently overwrites it. addSchemas unconditionally calls openAPI.getComponents().addSchemas(name, schema) (a map put) afterward, so e.g. inlineSchemaNameMapping: {Preview_balance: Money} with a pre-existing components.schemas.Money replaces the original Money definition and rebinds every existing $ref: '#/components/schemas/Money' to the inline schema. Guard the overwrite: only allow the explicit name to win when the existing entry was itself created by an earlier mapping, otherwise fall back to uniqueName(name) (or at least emit a warning before overwriting).

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At modules/openapi-generator/src/main/java/org/openapitools/codegen/InlineModelResolver.java, line 1187:

<comment>Mapped names now bypass the `components.schemas.containsKey(name)` check entirely, so a mapped value that collides with an existing spec-defined schema silently overwrites it. `addSchemas` unconditionally calls `openAPI.getComponents().addSchemas(name, schema)` (a map put) afterward, so e.g. `inlineSchemaNameMapping: {Preview_balance: Money}` with a pre-existing `components.schemas.Money` replaces the original `Money` definition and rebinds every existing `$ref: '#/components/schemas/Money'` to the inline schema. Guard the overwrite: only allow the explicit name to win when the existing entry was itself created by an earlier mapping, otherwise fall back to `uniqueName(name)` (or at least emit a warning before overwriting).</comment>

<file context>
@@ -1182,13 +1182,12 @@ private void copyVendorExtensions(Schema source, Schema target) {
-        // Recursive flattening can add a nested schema after its parent's name
-        // was chosen. Re-check here so the parent cannot overwrite that child.
-        if (openAPI.getComponents().getSchemas().containsKey(name)
+        } else if (openAPI.getComponents().getSchemas().containsKey(name)
                 || uniqueNames.contains(name)) {
+            // Recursive flattening can add a nested schema after its parent's name
</file context>

[mohitduhan19]

Using the mapped name as is matches 7.25.0, where a mapping onto an existing schema name also replaced it, so I kept that behaviour rather than falling back to uniqueName. In 9867efd the resolver now logs a warning when a mapped name already exists in the spec and wasn't added by an earlier mapping. Several mappings onto the same name (the case from #25179) don't trigger it.

[wing328]

Thanks for the PR

cc @bold84 (author of #24760)

[bold84]

Thank you @mohitduhan19

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Re-trigger cubic</sub>