Skip to content

[AAASM-4518] 🐛 (deps): Relax pydantic/protobuf floors for framework compatibility - #244

Merged
Chisanan232 merged 2 commits into
masterfrom
v0.0.1/AAASM-4518/relax_dep_floors
Jul 13, 2026
Merged

[AAASM-4518] 🐛 (deps): Relax pydantic/protobuf floors for framework compatibility#244
Chisanan232 merged 2 commits into
masterfrom
v0.0.1/AAASM-4518/relax_dep_floors

Conversation

@Chisanan232

Copy link
Copy Markdown
Contributor

Description

The published, immutable agent-assembly==0.0.1rc4 sharply raised its runtime
dependency floors, making it un-co-installable with three mainstream agent
frameworks — a compat regression vs rc.3 (surfaced by 3 red lanes on examples#268).

Root cause. Commit 0106ab9 (AAASM-4434, "Pin pyproject.toml floors to
explicitly reflect resolved versions") pinned each floor to whatever the dev
lockfile happened to resolve to — not to a minimum the SDK actually needs:

dep rc.3 rc.4 (regressed) this PR
pydantic >=2.0.0 >=2.13.4 >=2.0.0
protobuf >=5 >=6.33.6 >=5
grpcio >=1.66 >=1.82.1 >=1.66

Those floors are unsatisfiable against current framework releases:

  • AutoGenautogen-core>=0.7.5 caps protobuf>=5.29.3,<5.30 vs rc.4 >=6.33.6.
  • CrewAIcrewai>=1.15.2 caps pydantic>=2.11.9,<2.13 vs rc.4 >=2.13.4.
  • Semantic Kernelsemantic-kernel>=1.30 caps pydantic<2.13 vs rc.4 >=2.13.4.

Why relaxing is safe (necessary-vs-over-tighten verdict).

  • pydantic / grpcio — pure over-tighten. The SDK only uses BaseModel / Field /
    model_dump (all stable since pydantic 2.0); grpcio's floor was never a real
    minimum. Restoring the rc.3 floors changes nothing the code relies on.
  • protobuf — restore rc.3, with a documented caveat. The checked-in gRPC stubs
    under agent_assembly/proto/ are gencode 6.31.1 and need a protobuf 6.x
    runtime to import (verified: protobuf 5.29 raises VersionError). But those stubs
    are imported only by the optional OpControl gRPC transport (op_control.py),
    never at package-import time — so mainstream framework quick-starts run fine under
    protobuf 5.x, exactly as they did on rc.3, which also shipped 6.31.1 gencode under
    a >=5 floor since 2026-05-21
    . This floor-vs-gencode nuance is pre-existing, not
    introduced here; a user needing the OpControl gRPC path must have protobuf>=6.31.1.
    Regenerating the stubs at 5.x gencode is a separate concern, out of scope for this
    compat fix.

Pre-publish guard. Adds scripts/ci/check_framework_resolution.py +
framework-resolution-check.yml: it resolves the SDK's declared floors (read live
from [project.dependencies]) against the framework matrix via uv pip compile, and
fails the PR if a floor excludes a supported framework — so this class of
floor-vs-framework regression is caught before an immutable wheel is published.

Type of Change

  • 🔧 Bug fix

Breaking Changes

  • No — this widens the accepted dependency range (strictly more permissive).

Related Issues

  • Related JIRA ticket: AAASM-4518
  • Related GitHub issues: examples#268 (held pending this fix)

Testing

  • Unit tests added/updated — new pre-publish resolver guard (check_framework_resolution.py)
  • Manual testing performed:
    • Full SDK suite green with relaxed floors: 782 passed, 16 skipped.
    • Resolution proof — SDK floors co-resolve with all three current framework releases:
      autogen-core>=0.7.5 (protobuf 5.29.6), crewai>=1.15.2 (pydantic 2.12.5),
      semantic-kernel>=1.30 (pydantic 2.11.10).
    • Guard passes on this tree and fails on the rc.4 floors (reproduces all 3 conflicts).

Note on release / examples#268

rc.4 is immutable on PyPI, so this ships in rc.5 — the published rc.4 stays broken.
examples#268 goes green only after rc.5 is published, not when this PR merges.

Checklist

  • Code follows project style guidelines
  • Self-review completed
  • Comments added for complex logic (WHY-comments on each relaxed floor + the protobuf caveat)
  • All tests passing

AAASM-4434 pinned the runtime dependency floors to the then-resolved
versions (pydantic>=2.13.4, protobuf>=6.33.6, grpcio>=1.82.1). Those are
not minimums the SDK needs — they made agent-assembly un-co-installable
with three mainstream frameworks, a regression vs rc.3:

- CrewAI (caps pydantic<2.13) and Semantic Kernel (<2.12) vs >=2.13.4
- AutoGen (autogen-core caps protobuf<5.30) vs >=6.33.6

Restore the rc.3 floors (pydantic>=2.0.0, protobuf>=5, grpcio>=1.66) —
the true minimums the code needs — and regenerate uv.lock (resolved
versions unchanged; only the requires-dist specifiers move). Documents
the pre-existing caveat that the checked-in gRPC stubs are gencode
6.31.1 (need a protobuf 6.x runtime for the optional OpControl path).

Refs: AAASM-4518
Resolves agent-assembly's declared runtime floors (read live from
[project.dependencies]) together with each supported framework at its
current release floor (AutoGen / CrewAI / Semantic Kernel), via
`uv pip compile` as an offline-metadata solve. Fails the PR if a floor
excludes a framework's supported range — catching the class of
floor-vs-framework regression that shipped in rc.4 (AAASM-4518) BEFORE
the immutable wheel is published, instead of after.

Refs: AAASM-4518
@codecov

codecov Bot commented Jul 13, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@sonarqubecloud

Copy link
Copy Markdown

@Chisanan232

Copy link
Copy Markdown
Contributor Author

Claude Code review — AAASM-4518 (relax over-tightened dep floors + pre-publish resolver guard)

1. CI — PASS. All required checks green (Analyze, unit/integration/contract tests, CodeQL, pip-audit, PEP 561, SonarCloud, docs). The new framework-resolution-check / "Dependency floors co-resolve with supported frameworks" guard passes. Only skips are release-deploy lanes (expected on a PR) and coverage/Sonar-acceptance (out of scope). No real failures.

2. Scope vs ticket — PASS, matches exactly. Floors relaxed to the true minimums with upper bounds kept: pydantic >=2.13.4 → >=2.0.0,<3, protobuf >=6.33.6 → >=5,<8, grpcio >=1.82.1 → >=1.66,<2. uv.lock regenerated to match. New scripts/ci/check_framework_resolution.py + .github/workflows/framework-resolution-check.yml resolve the SDK's live [project.dependencies] floors against AutoGen/CrewAI/Semantic Kernel via uv pip compile (offline metadata SAT solve) and fail on a floor regression. Verified the guard actually works both ways: with the relaxed floors it reports OK for all three frameworks (exit 0); patched back to the rc.4 floors it correctly FAILS, naming the pydantic vs semantic-kernel/CrewAI conflict (exit 1). Genuine pre-publish gate, not a no-op. Ready to merge (ships rc.5).

3. Side effects — PASS. Relaxing floors only widens compatibility; no existing install can break. No dep is now under-constrained for the SDK's real API usage — it uses pydantic BaseModel/Field/model_dump, all stable since 2.0. protobuf >=5 caveat is a restored rc.3 status-quo, NOT a new break: the checked-in gRPC stubs are gencode 6.31.1 (need protobuf 6.x runtime), but they are imported only on the optional OpControl gRPC transport (op_control.py), never at package-import time — mainstream framework quick-starts run fine under protobuf 5.x, exactly as they did on rc.3 (which shipped the same 6.31.1 gencode under >=5 since 2026-05-21). Users on the OpControl path already needed protobuf>=6.31.1 then and now. SDK test suite green in the worktree: 782 passed, 16 skipped, 0 failed.

4. Frontend — N/A. Deps + a CI script only; no UI surface, no Playwright.

Overall: APPROVE. Fix is correct, minimal, in-scope, and adds a real pre-publish guard against this regression class. Ships in rc.5 — rc.4 is immutable on PyPI so the compat fix can't be retrofitted; examples#268 (sdk-versions bump) unblocks only once rc.5 publishes.

Automated review by Claude Code. Not merging; no Jira transition.

@Chisanan232
Chisanan232 merged commit fbeef8e into master Jul 13, 2026
31 checks passed
@Chisanan232
Chisanan232 deleted the v0.0.1/AAASM-4518/relax_dep_floors branch July 13, 2026 07:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant