Skip to content

chore(deps): uv: bump the all-python group across 1 directory with 9 updates #828

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dependabot wants to merge 1 commit into
base: main
Choose a base branch
from
Open

chore(deps): uv: bump the all-python group across 1 directory with 9 updates #828

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions agent/pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,13 +15,13 @@ dependencies = [
# try/except (ImportError, AttributeError), so removing this dep
# would degrade gracefully — but for now we keep the dep to
# preserve the clean code path.
"bedrock-agentcore==1.18.1", #https://pypi.org/project/bedrock-agentcore/
"claude-agent-sdk==0.2.110", #https://github.com/anthropics/claude-agent-sdk-python/releases/tag/v0.2.110 (bundles claude CLI 2.1.191; kept in lockstep with the npm CLI pin in the Dockerfile, #215)
"bedrock-agentcore==1.22.0", #https://pypi.org/project/bedrock-agentcore/
"claude-agent-sdk==0.2.144", #https://github.com/anthropics/claude-agent-sdk-python/releases/tag/v0.2.110 (bundles claude CLI 2.1.191; kept in lockstep with the npm CLI pin in the Dockerfile, #215)

@scottschreckengaust scottschreckengaust Sep 1, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BLOCKING (B2) — this bump breaks the #215 SDK↔CLI lockstep, and the trailing comment now asserts the opposite of the pin.

I read _cli_version.py at both upstream tags:

  • v0.2.110 → __cli_version__ = "2.1.191"
  • v0.2.144 → __cli_version__ = "2.1.246"

agent/Dockerfile:90 still installs @anthropic-ai/claude-code@2.1.191, so the image ships an SDK expecting CLI 2.1.246 beside an on-PATH CLI at 2.1.191 — against the invariant agent/Dockerfile:76-80 states in its own words ("the SDK and the on-PATH CLI must agree on the control protocol"). A control-protocol mismatch surfaces as opaque subprocess failures deep in a long-running task.

The comment on this line is now doubly false: it links the v0.2.110 release tag and claims "(bundles claude CLI 2.1.191; kept in lockstep with the npm CLI pin in the Dockerfile, #215)". Two more sites repeat it: agent/Dockerfile:76 and docs/design/BEDROCK_COST_ATTRIBUTION.md:89 (+ generated mirror docs/src/content/docs/architecture/Bedrock-cost-attribution.md:93).

Fix: bump the Dockerfile to 2.1.246, re-verify the install.cjs / claude --version shim guard at Dockerfile:88-94, correct all four prose sites, re-run mise //docs:sync. Then close the loop structurally — dependabot's uv ecosystem cannot see the npm pin in the Dockerfile, so it structurally cannot keep this lockstep and will reopen this PR forever. Either add claude-agent-sdk to the ignore: list alongside cedarpy, or add a check:claude-cli-lockstep guard to mise run drift-prevention that diffs claude_agent_sdk._cli_version.__cli_version__ against the Dockerfile pin. #215 has drifted twice now; the third time should be caught by a script, not a reviewer.

"requests==2.34.2", #https://pypi.org/project/requests/
"fastapi==0.139.0", #https://pypi.org/project/fastapi/
"uvicorn==0.50.0", #https://pypi.org/project/uvicorn/
"aws-opentelemetry-distro==0.18.0", #https://pypi.org/project/aws-opentelemetry-distro/
"mcp==1.28.1", #https://pypi.org/project/mcp/
"fastapi==0.141.1", #https://pypi.org/project/fastapi/
"uvicorn==0.52.4", #https://pypi.org/project/uvicorn/
"aws-opentelemetry-distro==0.19.0", #https://pypi.org/project/aws-opentelemetry-distro/
"mcp==2.0.0", #https://pypi.org/project/mcp/

@scottschreckengaust scottschreckengaust Sep 1, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BLOCKING (B1) — mcp 1.28.1 → 2.0.0 is a major release that renames or deletes every symbol agent/src/gateway_tools.py uses. Verified against upstream tag v2.0.0:

  • streamablehttp_client → streamable_http_client (src/mcp/client/streamable_http.py:640)
  • that function no longer accepts auth= or timeout= — signature is (url, *, http_client: httpx2.AsyncClient | None = None, terminate_on_close: bool = True); SigV4 auth and the timeout must now ride on a caller-supplied httpx2.AsyncClient
  • it yields TransportStreams = tuple[ReadStream, WriteStream] (src/mcp/client/_transport.py:13) — a 2-tuple, so gateway_tools.py:164-168's as (read, write, _get_session_id) raises ValueError
  • ClientSession.call_tool(read_timeout_seconds=…) is now float | None, not timedelta (gateway_tools.py:178)
  • mcp.shared.exceptions.McpError → MCPError (gateway_tools.py:212)
  • mcp 2.0.0 depends on httpx2 (module httpx2), and the httpx entry is deleted from agent/uv.lock — so import httpx at gateway_tools.py:46/85/206 no longer resolves

Net effect: with enableToolGateway=true, every repo_config call raises ImportError at line 161, _expected_gateway_errors() silently loses both httpx.HTTPError and McpError to its except ImportError: pass, and the failure lands in the broad except Exception → a log_error_cw operator error per tool call plus a bogus isError result to the model. Feature 100% dead, diagnostics actively misleading.

Also: httpx is used in src/gateway_tools.py and tests/test_gateway_tools.py:270 but never declared here — it free-rode on mcp's transitive pin, the exact trap the comment at lines 44-48 says was fixed for pyyaml/jsonschema. Declare httpx2 explicitly.

Suggested: split mcp 2.x into its own issue + PR with the migration, and add mcp version-update:semver-major to the .github/dependabot.yml ignore: block (mirroring the cedarpy precedent at :47-54) so a breaking transport change gets its own reviewable PR.

# CEDAR ENGINE PARITY — DO NOT BUMP IN ISOLATION.
# cedarpy (Python, agent runtime) and @cedar-policy/cedar-wasm (TypeScript,
# CDK Lambdas) are two language bindings over the same Cedar Rust core.
Expand Down Expand Up @@ -87,7 +87,7 @@ dev = [
"ruff",
"ty",

@scottschreckengaust scottschreckengaust Sep 1, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BLOCKING (B3) — the lock moves ty 0.0.56 → 0.0.73, which re-runs the exact regression that killed #626 and #590. build (agentcore) is RED with 14 diagnostics (job 99062295464); 7 are the frozen-Pydantic pattern:

error[invalid-assignment]: Property `filename` defined in `PreparedAttachment` is read-only
  --> tests/test_attachments.py:46:13
error[invalid-assignment]: Property `author` defined in `IssueComment` is read-only
  --> tests/test_models.py:30:13
... also test_models.py:63, :140, :170, :431, :462

Every one of those lines sits inside with pytest.raises(ValidationError): — the tests assert runtime immutability of frozen models and are correct as written. ty 0.0.73 has simply started reporting statically what the tests deliberately do at runtime. Weakening the assertions would trade real coverage for a green tool.

Fix: targeted # ty: ignore[invalid-assignment] on each of the 7 lines (or a scoped [tool.ty.rules] override for tests/), landed as its own reviewed change with a rationale comment — the same shape as the existing deprecated = "ignore" entry at line 180-181.

Standing suggestion: this is the third 0.0.x ty bump to flip the build red. Since the gate is uv run ty check (agent/mise.toml:45) and ty is pre-1.0, consider a dependabot ignore for ty so it is bumped deliberately rather than weekly.

"pytest",
"pygments==2.20.0",
"pygments==2.21.0",
"pytest-cov==7.1.0",
"pytest-timeout==2.4.0", # per-test wall-clock cap: a single hung test (network/subprocess/Bedrock without its own timeout) must fail LOUDLY with a traceback, not silently burn the whole build-verify budget (ABCA-684/686: one hang stalled the baseline build past its 3600s ceiling)
"vulture==2.16", # dead-code detection (#282): unused functions/classes ruff F can't see
Expand Down
Loading
Loading