fix(openapi): handle non-numeric OpenAPI response keys in return-doc generation

[Diwak4r]

Problem

PydocHelper.generate_return_doc sorts an operation's OpenAPI Responses Object with int(item[0]) as the sort key:

sorted_responses = sorted(responses.items(), key=lambda item: int(item[0]))

The OpenAPI 3.x spec allows the Responses Object to be keyed by non-numeric values in addition to numeric status codes: the default catch-all (very common in real specs) and range codes (1XX, 2XX, 3XX, 4XX, 5XX). For any of these keys, int(...) raises ValueError.

This is reachable from normal usage: OperationParser.get_pydoc_string() passes operation.responses straight through, so building an OpenAPIToolset from any spec whose operation declares a default response crashes with an opaque ValueError: invalid literal for int() with base 10: 'default' instead of parsing the tool.

Fix

Sort numeric status codes as before and place non-numeric keys after them:

key=lambda item: int(item[0]) if item[0].isdigit() else float('inf')

The existing r[0].startswith('2') content filter still selects the smallest 2xx response with content, so behavior for numeric keys is unchanged.

How verified

• Reproduced the pre-fix crash with a default response key.
• Added test_generate_return_doc_non_numeric_status_keys alongside the existing test_generate_return_doc_* cases.
• pytest tests/unittests/tools/openapi_tool/common/test_common.py → 43 passed (was 42).

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.