fix(core): avoid dangling request-model import for skipped form models

[SubhamAshok]

PR checklist

• Read the contribution guidelines.
• 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
  

• Target language technical committee: @wing328 @diyfr @jpfinne

Description of the change

Fixes #24727.

When an operation's requestBody defines multiple content types (for example, application/json and multipart/form-data), InlineModelResolver creates an inline model for the form schema. In DefaultCodegen#getContent, all media types in requestBody.getContent() were unconditionally adding their schema types to imports.

When skipFormModel is enabled (default true), DefaultGenerator skips generating the model class for schemas used only in form parameters. This caused the generated API interface to emit a dangling import for a non-existent model class and fail compilation.

This fix updates DefaultCodegen#getContent to avoid registering imports for form/multipart media types when skipFormModel is enabled.

Tests

• Added testMultipleRequestBodyContentTypesDanglingImport_issue24727 and testMultipleRequestBodyContentTypesWithSkipFormModelFalse_issue24727 in SpringCodegenTest.java.
• Verified SpringCodegenTest, DefaultCodegenTest, and ModelUtilsTest all pass.

---

Summary by cubic

Fixes #24727 so DefaultCodegen#getContent no longer emits dangling imports for form models skipped by skipFormModel (default true). Previously every form/multipart schema type was added to imports even when its model class wasn't generated, which broke compilation; now only schemas used exclusively in form parameters are filtered out, and shared form models still generate.

Bug Fixes

• Adds isFormContentType, isSkipFormModel, and a cached getSchemasUsedOnlyInFormParam lookup in DefaultCodegen.
• DefaultGenerator resolves skipFormModel once in configureGeneratorProperties, stores the normalized value in additionalProperties, and generateModels reads it from there so generation and import filtering use the same value.
• Adds three SpringCodegenTest cases and fixtures issue_24727.yaml and issue_24727_shared.yaml covering default behavior, skipFormModel=false, and shared form models.

^{Written for commit b16feb6. 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. If appropriate, use sub-agents to investigate and fix each issue separately.


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

<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java:8311">
P2: The import-suppression signal here diverges from how DefaultGenerator decides whether a form model is actually generated. DefaultGenerator skips a model only when it is listed in `unusedModels` (used exclusively as a form parameter), and it resolves the `skipFormModel` default through `getGeneratorPropertyDefaultSwitch(CodegenConstants.SKIP_FORM_MODEL, true)`, which honors per-generator `generatorPropertyDefaults`. The new `isSkipFormModel()` instead always falls back to `GlobalSettings` default `"true"` and the condition suppresses imports purely on content type, ignoring whether the model is in `unusedModels`. When a multipart request-body schema references a model that is genuinely generated (used elsewhere, so not in `unusedModels`), this condition drops its import, producing a missing-import failure — the inverse of the bug being fixed. The two signals should match.</violation>
</file>

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

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: The import-suppression signal here diverges from how DefaultGenerator decides whether a form model is actually generated. DefaultGenerator skips a model only when it is listed in unusedModels (used exclusively as a form parameter), and it resolves the skipFormModel default through getGeneratorPropertyDefaultSwitch(CodegenConstants.SKIP_FORM_MODEL, true), which honors per-generator generatorPropertyDefaults. The new isSkipFormModel() instead always falls back to GlobalSettings default "true" and the condition suppresses imports purely on content type, ignoring whether the model is in unusedModels. When a multipart request-body schema references a model that is genuinely generated (used elsewhere, so not in unusedModels), this condition drops its import, producing a missing-import failure — the inverse of the bug being fixed. The two signals should match.

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/java/org/openapitools/codegen/DefaultCodegen.java, line 8311:

<comment>The import-suppression signal here diverges from how DefaultGenerator decides whether a form model is actually generated. DefaultGenerator skips a model only when it is listed in `unusedModels` (used exclusively as a form parameter), and it resolves the `skipFormModel` default through `getGeneratorPropertyDefaultSwitch(CodegenConstants.SKIP_FORM_MODEL, true)`, which honors per-generator `generatorPropertyDefaults`. The new `isSkipFormModel()` instead always falls back to `GlobalSettings` default `"true"` and the condition suppresses imports purely on content type, ignoring whether the model is in `unusedModels`. When a multipart request-body schema references a model that is genuinely generated (used elsewhere, so not in `unusedModels`), this condition drops its import, producing a missing-import failure — the inverse of the bug being fixed. The two signals should match.</comment>

<file context>
@@ -8285,7 +8308,7 @@ protected LinkedHashMap<String, CodegenMediaType> getContent(Content content, Se
 
             cmtContent.put(contentType, codegenMt);
-            if (schemaProp != null) {
+            if (schemaProp != null && (!isFormContentType(contentType) || !isSkipFormModel())) {
                 addImports(imports, schemaProp.getImports(true, importBaseType, generatorMetadata.getFeatureSet()));
             }
</file context>

[HDPark95]

Verified at 3e336bb: reverting only DefaultCodegen.java fails the new dangling-import test, so it is pinned.

isSkipFormModel() reads GlobalSettings only, but DefaultGenerator resolves skipFormModel as GlobalSettings -> generatorPropertyDefaults -> true. On the issue spec with setGeneratorPropertyDefault(SKIP_FORM_MODEL, "false") I measured: model generated, import dropped, the opposite of what your second test asserts. That test also passes on unmodified master, so it does not cover this path.

Could the guard reuse that resolution, or getSchemasUsedOnlyInFormParam?

[SubhamAshok]

Thanks for the feedback! I updated the implementation:

1. Aligned \skipFormModel\ handling across \DefaultGenerator\ and \DefaultCodegen\ so settings passed via \generatorPropertyDefaults\ take effect properly.
2. In \DefaultCodegen.getContent(), imports are now filtered against \ModelUtils.getSchemasUsedOnlyInFormParam()\ so shared models referenced in form payloads keep their imports.
3. Added test cases covering default \skipFormModel=true, \skipFormModel=false\ via generator properties, and shared models.

[cubic-dev-ai]

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

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

Re-trigger cubic</sub>

[cubic-dev-ai]

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

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

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

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[jpfinne]

Create a general utility method to retrieve the best configuration

[jpfinne]

@SubhamAshok I had the same kind of issue when I wrote DefaultCodegen.convertPropertyToBooleanAndWriteBack

The configuration could come from a cliOption or from additionalProperties. Before there were discrepancies, leading to side effects if the code or the template used additionalProperties or getter in the CodeGen.

It think we could have the same for GlobalSettings.

Maybe we can have something like:
boolean convertGlobalSettingsPropertyToBooleanAndWriteBack(String propertyKey, Consumer<Boolean> booleanSetter, Supplier<Boolean> defaultIfMissing)

[SubhamAshok]

Thanks for the suggestion! Added convertGlobalPropertyToBooleanAndWriteBack in DefaultGenerator to resolve the global/generator defaults and write them back into additionalProperties. configureGeneratorProperties and generateModels now use this single standard path.

[jpfinne]

@SubhamAshok Same as above. This looks way too convulated