feat: Add --use-status-code-in-response-name option

[koxudaxi]

Closes: #1828

Summary by CodeRabbit

Release Notes

• New Features

  • Added --use-status-code-in-response-name CLI option (OpenAPI-only) to automatically include HTTP status codes in generated response model names (e.g., ResourceGetResponse200).

• Documentation

  • Updated CLI reference documentation with comprehensive details about the new option and its usage.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The pull request introduces a new CLI flag --use-status-code-in-response-name that enables HTTP status codes to be appended to generated response model names in OpenAPI schemas. The feature threads a new boolean parameter through the CLI argument parser, configuration model, public generate() function, and OpenAPI parser, which uses the flag to construct response names with status code suffixes during response schema parsing.

Changes

Cohort / File(s)	Summary
Documentation docs/cli-reference/index.md, docs/cli-reference/openapi-only-options.md, docs/cli-reference/quick-reference.md	Added documentation entries for the new --use-status-code-in-response-name flag across CLI reference sections, including description, usage context, and alphabetical indexing.
CLI Infrastructure src/datamodel_code_generator/arguments.py, src/datamodel_code_generator/cli_options.py	Added new OpenAPI-specific CLI argument with store_true action and registered flag metadata in the CLI option catalog.
Configuration & API src/datamodel_code_generator/__init__.py, src/datamodel_code_generator/__main__.py	Extended Config model with new boolean field and threaded parameter through generate() function signature and run_generate_from_config entrypoint.
Core Logic src/datamodel_code_generator/parser/openapi.py	Updated OpenAPIParser to accept the flag, store it as instance attribute, and conditionally append capitalized status code to response names during parse_responses.
Test Data & Cases tests/data/openapi/use_status_code_in_response_name.yaml, tests/data/expected/main/openapi/use_status_code_in_response_name.py, tests/main/openapi/test_main_openapi.py	Added OpenAPI specification fixture, expected output with status-code-suffixed Pydantic models (ResourceGetResponse200, ResourceGetResponse400, ResourceGetResponseDefault), and integration test verifying the feature end-to-end.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Core logic change in OpenAPIParser: Review the conditional response name construction in parse_responses and ensure status code appending integrates correctly with existing schema resolution.
• Parameter threading: Trace the new parameter flow from CLI flag through Config, generate() signature, and OpenAPIParser initialization to verify consistent propagation and no missed wiring points.
• Test coverage: Validate that the test YAML fixture exercises all status code cases (200, 400, default) and that expected output models correctly reflect the naming scheme.

Possibly related PRs

• PR #2684: Modifies the same code paths (CLI argument parsing, Config model, generate() function signature, and main plumbing) for similar feature flag wiring.

Poem

🐰 A flag hops in, with status codes so fine,
Response names now shine with numbers aligned,
ResourceGetResponse200, 400, Default too,
No more confusion when parsing anew! ✨
The parser now knows which response is true.

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and accurately summarizes the main feature being added—a new CLI option for including HTTP status codes in response model names.
Linked Issues check	✅ Passed	The implementation successfully addresses issue #1828 by adding the --use-status-code-in-response-name flag that generates response models with status codes (e.g., ResourceGetResponse200, ResourceGetResponseDefault).
Out of Scope Changes check	✅ Passed	All changes are directly related to implementing the requested feature; no unrelated modifications to existing functionality or out-of-scope changes detected.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/use-status-code-in-response-name

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 67ea24b and 2e78cc2.

📒 Files selected for processing (11)

• docs/cli-reference/index.md (2 hunks)
• docs/cli-reference/openapi-only-options.md (2 hunks)
• docs/cli-reference/quick-reference.md (2 hunks)
• src/datamodel_code_generator/__init__.py (2 hunks)
• src/datamodel_code_generator/__main__.py (2 hunks)
• src/datamodel_code_generator/arguments.py (1 hunks)
• src/datamodel_code_generator/cli_options.py (1 hunks)
• src/datamodel_code_generator/parser/openapi.py (4 hunks)
• tests/data/expected/main/openapi/use_status_code_in_response_name.py (1 hunks)
• tests/data/openapi/use_status_code_in_response_name.yaml (1 hunks)
• tests/main/openapi/test_main_openapi.py (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (3)

src/datamodel_code_generator/parser/openapi.py (2)

src/datamodel_code_generator/model/base.py (1)

• name (599-601)

src/datamodel_code_generator/parser/base.py (1)

• data_type (974-976)

tests/data/expected/main/openapi/use_status_code_in_response_name.py (1)

src/datamodel_code_generator/model/base.py (1)

• name (599-601)

tests/main/openapi/test_main_openapi.py (1)

tests/main/conftest.py (2)

• output_file (94-96)
• run_main_and_assert (196-352)

🪛 Checkov (3.2.334)

tests/data/openapi/use_status_code_in_response_name.yaml

[high] 1-42: Ensure that the global security field has rules defined

(CKV_OPENAPI_4)

---

[high] 1-42: Ensure that security operations is not empty.

(CKV_OPENAPI_5)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: combine coverage
• GitHub Check: benchmarks

🔇 Additional comments (16)

docs/cli-reference/quick-reference.md (1)

131-131: LGTM!

The new option is correctly documented in both the categorized table and the alphabetical index with proper cross-references.

Also applies to: 266-266

tests/data/openapi/use_status_code_in_response_name.yaml (1)

1-40: LGTM! Test schema is well-structured.

The OpenAPI schema effectively tests the new feature with three response scenarios (200, 400, default), which should validate that status codes are correctly incorporated into generated model names.

Note: Static analysis warnings about missing security are expected for test fixtures and can be safely ignored.

src/datamodel_code_generator/__main__.py (2)

466-466: LGTM! Configuration field properly added.

The new boolean flag is correctly positioned alphabetically in the Config model with an appropriate default value of False.

---

769-769: LGTM! Flag properly threaded to generation.

The configuration value is correctly passed to the generate() function, completing the configuration flow from CLI → Config → generation logic.

docs/cli-reference/index.md (1)

16-16: LGTM! Documentation index properly updated.

The option count increment (5 → 6) and alphabetical index entry are both correct and maintain consistency with the new feature addition.

Also applies to: 175-175

src/datamodel_code_generator/cli_options.py (1)

184-186: LGTM! CLI option metadata properly registered.

The new option is correctly registered in the CLI_OPTION_META dictionary with appropriate categorization under OptionCategory.OPENAPI.

src/datamodel_code_generator/arguments.py (1)

716-721: LGTM! Argument parser definition is well-formed.

The CLI argument is properly configured with:

• Clear, descriptive help text with concrete examples
• Correct placement in the openapi_options group
• Standard boolean flag pattern (action="store_true", default=None)

docs/cli-reference/openapi-only-options.md (1)

930-1020: The --use-status-code-in-response-name section appears only once in the file (at line 930). No duplicate exists. Remove this review comment.

Likely an incorrect or invalid review comment.

tests/main/openapi/test_main_openapi.py (1)

4228-4249: LGTM! Well-structured test for the new feature.

The test properly exercises the --use-status-code-in-response-name flag with appropriate OpenAPI scopes and follows the established testing pattern. The docstring clearly explains the expected behavior with concrete examples.

src/datamodel_code_generator/__init__.py (2)

480-480: LGTM! Proper parameter addition with backwards-compatible default.

The new use_status_code_in_response_name parameter is correctly added to the generate() function signature with a safe default value of False.

---

540-540: LGTM! Correct parameter propagation to OpenAPI parser.

The parameter is appropriately passed to the OpenAPI parser only when input_file_type == InputFileType.OpenAPI, maintaining proper scope.

tests/data/expected/main/openapi/use_status_code_in_response_name.py (1)

12-23: LGTM! Expected output demonstrates the feature correctly.

The generated model names clearly show the feature in action:

• ResourceGetResponse200 for HTTP 200 responses
• ResourceGetResponse400 for HTTP 400 responses
• ResourceGetResponseDefault for default responses

This eliminates the ambiguity of positional suffixes mentioned in the issue.

src/datamodel_code_generator/parser/openapi.py (4)

275-275: LGTM! Parameter properly added to constructor.

The use_status_code_in_response_name parameter is correctly added with a backwards-compatible default value.

---

373-373: LGTM! Instance variable correctly assigned.

The parameter is properly stored as an instance variable for use in response parsing.

---

555-556: LGTM! Clean implementation of status-code-aware naming.

The naming logic correctly handles both numeric status codes (e.g., "200") and string keys (e.g., "default") by using str(status_code).capitalize():

• Numeric codes remain unchanged: "200" → "200"
• Text keys get capitalized: "default" → "Default"

---

570-570: LGTM! Response name correctly applied to schema parsing.

The computed response_name is appropriately passed to _parse_schema_or_ref, ensuring the status code suffix is included in the generated model name.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.53%. Comparing base (67ea24b) to head (2e78cc2).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2688   +/-   ##
=======================================
  Coverage   99.53%   99.53%           
=======================================
  Files          81       81           
  Lines       11358    11366    +8     
  Branches     1357     1357           
=======================================
+ Hits        11305    11313    +8     
  Misses         32       32           
  Partials       21       21           

Flag	Coverage Δ
unittests	99.53% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[codspeed-hq]

CodSpeed Performance Report

Merging #2688 will not alter performance

_{Comparing feat/use-status-code-in-response-name (2e78cc2) with main (67ea24b)}

Summary

✅ 52 untouched
⏩ 10 skipped¹

Footnotes

1. 10 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩