[PATCH] chore: merge develop to main

[alain-sv]

Release PR created by just ship patch. Merge this PR after required checks pass; the publish workflow will bump the patch version from the merge commit token.

[qodo-code-review]

PR Summary by Qodo

Refresh dependency floors and fix A2A route-scope test for FastAPI 0.139

⚙️ Configuration changes 🧪 Tests 📝 Documentation 🕐 10-20 Minutes

AI Description

• Raise runtime and extra dependency lower bounds to newer patched releases.
• Make A2A events scope test resilient to FastAPI included-router wrappers.
• Document the dependency/security refresh and test fix in the Unreleased changelog.

Diagram

graph TD
  A["Release patch"] --> B["pyproject.toml"] --> C["FastAPI >=0.139.0"] --> D["Router wrappers"] --> E["tests/test_a2a.py"]
  B --> F["docs/CHANGELOG.md"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Name the /a2a/events route and locate it via url_path_for / route name

• ➕ Avoids brittle structural introspection of router internals
• ➕ Makes tests more intention-revealing (assert on named route)
• ➖ Requires changing production route registration (route naming conventions)
• ➖ Still may need a fallback if name changes or multiple mounts exist

2. Assert scope behavior via request outcome instead of dependency inspection

• ➕ Black-box test aligned with user-visible authorization behavior
• ➕ Less coupled to FastAPI internal route/dependant structures
• ➖ Harder to guarantee you’re testing the exact dependency chain / scope guard
• ➖ May require additional fixtures or auth plumbing to isolate read vs write scopes

Recommendation: Current approach (recursive traversal through included-router wrappers) is a pragmatic minimal change: it preserves the existing direct dependency assertion while adapting to FastAPI’s new wrapper structure. Consider route naming in a follow-up if router structure churn continues across FastAPI upgrades.

Files changed (3) +38 / -12

Tests (1) +12 / -1

test_a2a.pyTraverse nested routers when locating /a2a/events route +12/-1

Traverse nested routers when locating /a2a/events route

• Introduces a small recursive iterator helper to walk FastAPI included-router wrappers via the 'original_router' attribute. Updates the route lookup in the read-scope test to use the flattened iterator, preserving the scope assertion under FastAPI 0.139.0.

tests/test_a2a.py

Documentation (1) +15 / -0

CHANGELOG.mdAdd Unreleased notes for dependency refresh and A2A test fix +15/-0

Add Unreleased notes for dependency refresh and A2A test fix

• Adds an Unreleased entry documenting updated dependency lower bounds and a test fix required for FastAPI 0.139.0 routing wrapper behavior. Includes a brief pass/skip/fail test run summary table.

docs/CHANGELOG.md

Other (1) +11 / -11

pyproject.tomlRaise runtime and optional dependency lower bounds +11/-11

Raise runtime and optional dependency lower bounds

• Bumps runtime lower bounds for FastAPI, sse-starlette, Typer, and Uvicorn. Updates several optional dependencies in the deploy and dev extras (e.g., boto3, google-cloud-run, hatch, pytest, pytest-asyncio, ruff).

pyproject.toml

ⓘ You are approaching your monthly quota for Qodo. Upgrade your plan

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3919acb948

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Keep the Secret Manager floor at the tested version

For published supervaizer[deploy] installs that are resolved without this repository's uv.lock, this lowers the allowed google-cloud-secret-manager version from the previous >=2.28.0 to >=2.23.0 while the refreshed lock still tests 2.28.0. That means constrained environments can now run the Cloud Run secret-manager deploy path against an older, unverified client than the prior release allowed; keep the lower bound at >=2.28.0 unless 2.23.x is intentionally supported and tested.

Useful? React with 👍 / 👎.

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 32 rules

1. Unverified lowered deploy bound ✓ Resolved 🐞 Bug ☼ Reliability

Description

pyproject.toml lowers the deploy extra lower-bound for google-cloud-secret-manager to
>=2.23.0, but the repo’s lockfile still resolves google-cloud-secret-manager==2.28.0, so
CI/tests won’t validate the declared minimum supported version. This can lead to a published lower
bound that isn’t actually supported/tested for the Cloud Run deploy path.

Code

pyproject.toml[57]

+    "google-cloud-secret-manager>=2.23.0",

Relevance

⭐⭐ Medium

No historical evidence team enforces testing declared minimum versions; deps updates usually just
refresh uv.lock (e.g., PR73).

PR-#73

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR changes the minimum allowed version to >=2.23.0, but the repository lockfile still pins
google-cloud-secret-manager to 2.28.0, so the test environment does not validate the new
minimum. The deploy driver directly imports and uses secretmanager.SecretManagerServiceClient,
making this minimum-version claim relevant to runtime behavior when using the deploy extra.

pyproject.toml[51-58]
uv.lock[605-620]
src/supervaizer/deploy/drivers/cloud_run.py[37-87]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pyproject.toml` declares a lower minimum version for `google-cloud-secret-manager` in the `deploy` extra than the version actually exercised by the repo lockfile, meaning the advertised lower bound is not validated by CI.

## Issue Context
- `pyproject.toml` now allows `google-cloud-secret-manager>=2.23.0` for `deploy`.
- `uv.lock` currently resolves `google-cloud-secret-manager` to `2.28.0`, so CI/test runs based on the lock won’t catch incompatibilities introduced by lowering the minimum.
- The Cloud Run deploy driver imports and uses `google.cloud.secretmanager.SecretManagerServiceClient`, so this is a real runtime path for the `deploy` extra.

## Fix Focus Areas
- pyproject.toml[51-58]
- uv.lock[605-620]
- src/supervaizer/deploy/drivers/cloud_run.py[37-87]

## Suggested fix
Choose one of:
1) Restore the previous lower bound (e.g., `>=2.28.0`) to match the version you’re actually locking/testing, or
2) Keep `>=2.23.0` but add a CI job (or a dedicated constraints/lock) that installs and runs deploy-path checks/tests against the minimum supported version set (or at least `google-cloud-secret-manager==2.23.*`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---