feat: show schema names in request body details

[jessedegans]

Overview

When viewing endpoint details, request bodies now display the schema name alongside the media type, making it easier to understand what data structure is expected without leaving the current view.

What Changed

Before:

Request Body:
  - application/json

After:

Request Body:
  Description: Create a new pet in the store
  Required: true
  - application/json (schema: Pet)
  - application/x-www-form-urlencoded (schema: Pet)
  - application/xml (schema: Pet)

Implementation

• Extracts schema reference names from $ref paths (e.g., #/components/schemas/Pet → Pet)
• Shows inline schema types when no reference is used (e.g., object, string)
• Displays request body description and required status when present
• Maintains alphabetical ordering of media types

This keeps the interface clean and minimal > users see which schema is used in the Requests view, and can navigate to the Components tab for full schema details.

Testing

• Added TestPetstoreRequestBodySchemaDisplay to validate schema reference extraction
• Verified with petstore-3.0.yaml which uses $ref extensively
• All existing tests pass

Example

View the "Add a new pet to the store" endpoint in petstore-3.0.yaml to see the enhancement in action.

Summary by CodeRabbit

• New Features
  • Enhanced request body endpoint details rendering to display descriptions when present
  • Added required status indicators for request bodies
  • Improved media type presentation with schema details
  • Media types now display referenced schema names or inline schema types in parentheses for clearer schema identification

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

[coderabbitai]

Walkthrough

Enhanced OpenAPI RequestBody endpoint details rendering to display description and required status. Media type display now includes schema references or inline type information in parentheses for improved clarity.

Changes

Cohort / File(s)	Summary
RequestBody rendering enhancements oas.go	Added description and required flag display for RequestBody; extended media type display with schema references ($ref) or inline type annotations (object/string/etc.)
RequestBody schema display test oas_test.go	Added TestPetstoreRequestBodySchemaDisplay test case (duplicated) validating RequestBody schema display for POST /pet endpoint, verifying description, required status, and alphabetically sorted media types with schema references

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Verify RequestBody schema reference extraction logic and inline type inference work correctly across different schema structures
• Validate test assertions match the updated display formatting and media type sorting behavior
• Confirm handling of edge cases (missing descriptions, optional request bodies, unsupported schema types)

Possibly related PRs

• #32: 3.0, 3.1, 3.2 #36: RequestBody rendering changes overlap with prior libopenapi migration work on the same formatting logic
• feat: more examples #13: Both PRs modify request/response content type rendering in oas.go, including schema display and deterministic media type sorting

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: displaying schema names alongside media types in request body details, which is the core focus of the PR.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

oas.go (1)

281-329: Request body rendering is correct; consider sharing schema formatting helper

The new request-body rendering logic in formatEndpointDetails correctly:

• emits description and Required: true when set, and
• shows either $ref-derived schema names or inline type/types for each media type, with stable alphabetical ordering.

Two optional refinements:

• Factor the (schema: …)/(type: …) construction into a small helper shared with formatRequestBodyDetails (and possibly formatResponseDetails) to avoid duplication and to let component request bodies also show $ref schema names.
• When splitting the $ref, consider guarding against an empty last segment to avoid emitting "(schema: )" for malformed refs.

oas_test.go (1)

275-347: Good coverage of new request-body display; consider loosening description assertion

This test thoroughly exercises the new behavior (description, required flag, schema refs for all media types, and alphabetical ordering) and is well-structured.

One thing to consider: matching the request body description via the exact string "Create a new pet in the store" tightly couples the test to the example spec’s wording. If that description is edited (while still being rendered correctly), the test will fail. You could instead:

• assert on the presence of "Description:" plus a shorter, more stable substring, or
• read the expected description from the parsed model and assert that it appears.

Everything else in the test looks solid for the intended behavior.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c3bbc75 and 0ad9b6d.

📒 Files selected for processing (2)

• oas.go (2 hunks)
• oas_test.go (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

oas_test.go (1)

model.go (2)

• NewModel (212-229)
• Model (67-80)

[plutov]

Looks good, thank you!

[rehmannadeem520-hue]

40ff61e