fix(deps): bump openapi-python-client to 0.29.1 past advisory

[swkeever]

Change

• Tracks: https://konghq.atlassian.net/browse/VOL-1081 (epic VOL-1077)
• Aikido: AIKIDO-2026-62968 in openapi-python-client (high, due 2026-10-24)
• Upstream: GHSA-5293-mq8x-g3xj, fixed in 0.29.1

openapi-python-client generates src/volcano_sdk/_generated and is only a dev dependency. Before 0.29.1, a malicious OpenAPI document could make it generate arbitrary code. Our input is Hosting's bundled spec, so the practical risk was low, but the dev pin and uv.lock still carried the vulnerable release.

	Before	After
openapi-python-client (pyproject.toml dev pin and uv.lock)	0.29.0	0.29.1

uv lock --upgrade-package openapi-python-client moved only this package. Its dependency list is unchanged. scripts/generate_openapi.py runs whatever version is installed, and nothing else pins the generator.

Why this isn't only a lock bump

0.29.1's release notes say all custom templates break, because the fix wraps OpenAPI-sourced strings so templates must escape them explicitly. This repo overrides two templates, openapi/templates/endpoint_module.py.jinja and endpoint_macros.py.jinja. Both were copies of the 0.29.0 originals, and with a lock-only bump scripts/generate_openapi.py crashed (TypeError: unsupported operand type(s) for +: 'PythonCode' and 'str'). That would have failed the generated freshness check in CI.

• Templates. I took the 0.29.1 originals and reapplied the repo's existing customizations: the non-underscored request_kwargs and build_response helper names, and UUID | str for UUID parameters. The only adaptation is (parameter.to_string() | as_unembedded_code).replace(...), because to_string() now returns a wrapper instead of a str. A diff against upstream 0.29.1 shows nothing beyond those customizations, so the upstream escaping fixes now apply here too.
• Regenerated client. This touches 161 files under src/volcano_sdk/_generated and is all generator output. I compared each changed module's AST before and after, ignoring docstrings. The only executable change is client.py, where the set_httpx_client, set_async_httpx_client and __enter__/__aenter__ return annotations change from "Client"/"AuthenticatedClient" to typing.Self. Everything else is text:
  • # noqa: PLC0415 on the lazy model imports (420 lines)
  • docstrings rendered with plain " instead of r""" with \" escapes
  • empty model docstrings dropped
• Model renames. 0.29.1 changes how it PascalCases the callOAuthProviderAPI operation, so six models change from CallOAuthProviderAPI* to CallOAuthProviderApi*, with the same module paths. The handwritten private modules and tests that import them follow the new names. That's 15 lines across _auth_values.py, _transport_auth_account.py, _transport_types.py, _tests/test_state.py and _tests/test_auth_parser_boundaries.py. These are internal types under _generated and the private _transport* modules, so the public API doesn't change.

Verification

uv run --locked poe checks passes locally with uv 0.12.17 and CPython 3.12.14:

• policy: pass
• audit: No known vulnerabilities found
• generated: OpenAPI generated client is up to date
• lint / format-check: pass
• types: mypy no issues found in 172 source files, basedpyright 0 errors
• test / coverage: 2336 passed, 100.00% coverage
• package-check / package-extras: wheel and sdist built, quickstarts passed, all tox package envs OK

I didn't run the mutation jobs locally. The handwritten changes are identifier renames only.

Cross-language impact

Classification: none. This is a dev-dependency bump with internal generated-code churn. The wire contract, public facade and behavior don't change.

• Requirement IDs and affected behavior: none.
• JavaScript / Python / Ruby companion PRs: none needed. The generator is Python-only, and the JavaScript and Ruby SDKs use their own generators.
• Canonical scenarios, bindings and active/staged copies: unchanged.
• Public examples updated in each affected language: none. No public API changed.
• Native checks and shared acceptance evidence: the native checks above. I ran no live acceptance.

🤖 Generated with Claude Code

[swkeever]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-06T13:33:49.656452Z	f18e0b4	Manual request
🔒 Security Review	✅ Completed 2026-10-06T13:34:06.943466Z	f18e0b4	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. More of your lovely PRs please.

Reviewed commit: f18e0b4731

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

🛡️ Codex Security Review · Automatically triggered

Security review completed. No security issues were found in this pull request.

Reviewed commit: f18e0b4731

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.