fix(openapi): use exact-match dedup in default_operation_id_creator

[chuenchen309]

What

default_operation_id_creator can generate identical operationIds for two structurally different routes, violating the uniqueness OpenAPI requires of operationId (and which this codebase's own test_routes_with_different_paths_should_generate_unique_operation_ids already asserts for the cases it covers).

Root cause

components_namespace = ""
for component in (...):
    if component.title() not in components_namespace:
        components_namespace += component.title()

The dedup check is a substring check against the concatenated components_namespace string, not an exact-match check against the individual components seen so far. So if a later component's title happens to be a substring of the already-built string, it gets silently dropped — even though it's a distinct path component.

Example: path components ["users"] vs ["users", "user"].

• ["users"] → components_namespace = "Users".
• ["users", "user"] → "Users" added, then "User" is checked: "User" in "Users" → True (substring!) → the "user" component is dropped. Result stays "Users".

Both routes now produce the operationId UsersGetHandler, even though they represent different paths.

Fix

Track the set of components already seen (by exact value) instead of doing substring containment against the concatenated string:

components_namespace = ""
seen_components: set[str] = set()
for component in (...):
    title = component.title()
    if title not in seen_components:
        seen_components.add(title)
        components_namespace += title

This preserves the original intent — skip an exact-duplicate component (e.g. a router prefix literally repeating a path segment name) — without dropping components that merely share a substring with something already accumulated.

How I verified this

• Reproduced the collision directly against default_operation_id_creator: ["users"] and ["users", "user"] both produced "UsersGetHandler".
• Added a regression test, test_default_operation_id_creator_does_not_collide_on_component_substring, in tests/unit/test_openapi/test_path_item.py; confirmed it fails on the current code (AssertionError: 'UsersGetHandler' != 'UsersGetHandler').
• Applied the fix, confirmed the new test and all 23 tests in test_path_item.py pass.
• Ran the full tests/unit/test_openapi/ suite: 262 passed, no regressions.
• mypy litestar/_openapi/utils.py — clean.
• pre-commit run on changed files — clean (ruff check/format, unasyncd, typos).

Disclosure

I used AI assistance (Claude) to help investigate and draft this fix, but I personally reproduced the collision, wrote/reviewed the regression test, ran the full suite myself, and reviewed the final diff before submitting. Happy to answer any questions.

---

📚 Documentation preview 📚: https://litestar-org.github.io/litestar-docs-preview/4923

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 67.30%. Comparing base (bd18fd4) to head (fe874de).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
litestar/_openapi/utils.py	80.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4923   +/-   ##
=======================================
  Coverage   67.29%   67.30%           
=======================================
  Files         293      293           
  Lines       15228    15231    +3     
  Branches     1728     1728           
=======================================
+ Hits        10248    10251    +3     
  Misses       4833     4833           
  Partials      147      147           

☔ View full report in Codecov by Harness.
📢 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.