Python: [Bug]: agent-framework-ag-ui caps fastapi<0.140.0, which excludes every current release

[BenTaylorDev]

Description

agent-framework-ag-ui 1.2.2 declares fastapi>=0.121.0,<0.140.0. fastapi has been at 0.141.1 since 2026-07-29. Two consequences follow for a consumer:

1. A project already on a current fastapi cannot add the AG-UI connector at all. The resolve is unsatisfiable.
2. A fresh install of the connector holds the project at fastapi 0.139.2, which is two minor versions behind.

The bound last moved on 2026-07-28 in #7342, from <0.138.1 to <0.140.0. fastapi 0.140.0 had shipped four days earlier, and 0.141.0 shipped the next day, so the ceiling was current for about one day.

My question is whether <0.140.0 guards a known breakage, or whether it is the residue of the resolver conflict recorded in #7339. The evidence I can see points to the second reading, so I would rather ask than assume.

The failure output in #7339 does not name a fastapi incompatibility. It names a sibling package:

Because ... agent-framework-devui depends on fastapi>=0.115.0,<0.138.1 ...
And because you require fastapi==0.139.2 and agent-framework-devui,
we can conclude that your requirements are unsatisfiable.

#7342 describes that class of result as a false conflict, caused by package-scoped probes that were "following every optional extra and dependency group on transitive workspace packages", which "pulled in the unrelated core[all] surface and DevUI's FastAPI constraint". That PR fixed part of the probe and expanded the validated range "through 0.139.x", which is where the bound sits today.

On main right now, two sibling packages still declare the older ceiling: devui (python/packages/devui/pyproject.toml, fastapi>=0.115.0,<0.138.1) and hosting-responses. I can reproduce their effect on a consumer, below.

If the reading above is right, then raising the AG-UI bound needs one of two things first: those siblings move off <0.138.1, or the probe isolation from #7342 extends far enough that AG-UI stops inheriting their ceiling. That is why I am reporting it here rather than opening a pull request against the bound alone.

Code Sample

Three resolves against current published versions, on 2026-09-03. Nothing here is workspace-local.

# 1. A project on a current fastapi cannot add the connector.
$ printf 'agent-framework-ag-ui==1.2.2\nfastapi==0.141.1\n' > requirements.in
$ uv pip compile requirements.in --python-version 3.12
# -> unsatisfiable, output below

# 2. The connector alone holds the project two minors back.
$ printf 'agent-framework-ag-ui==1.2.2\n' > alone.in
$ uv pip compile alone.in --python-version 3.12
agent-framework-ag-ui==1.2.2
fastapi==0.139.2

# 3. Adding devui lowers the ceiling further, to 0.138.0.
$ printf 'agent-framework-ag-ui==1.2.2\nagent-framework-devui\n' > withdevui.in
$ uv pip compile withdevui.in --python-version 3.12
agent-framework-ag-ui==1.2.2
agent-framework-devui==1.0.0b260903
fastapi==0.138.0

# 4. An override is the only way through for case 1.
$ uv pip compile alone.in --python-version 3.12 --override <(printf 'fastapi==0.141.1\n')
agent-framework-ag-ui==1.2.2
fastapi==0.141.1

In a real project the override goes in pyproject.toml:

[tool.uv]
override-dependencies = ["fastapi==0.141.1"]

Error Messages / Stack Traces

  × No solution found when resolving dependencies:
  ╰─▶ Because agent-framework-ag-ui==1.2.2 depends on
      fastapi>=0.121.0,<0.140.0 and you require agent-framework-ag-ui==1.2.2,
      we can conclude that you require fastapi>=0.121.0,<0.140.0.
      And because you require fastapi==0.141.1, we can conclude that your
      requirements are unsatisfiable.

The message is accurate, but it does not tell a consumer whether the bound is protective. That is the part I cannot answer from the outside.

Package Versions

agent-framework-ag-ui: 1.2.2, agent-framework-core: 1.17.0, agent-framework-devui: 1.0.0b260903, fastapi: 0.141.1

Python Version

Python 3.12 for the resolves above. Python 3.12.13 for the round trip described below.

Additional Context

The override looks safe in practice, on one round trip. On agent-framework-ag-ui 1.1.0 with agent-framework-core 1.14.0 and Python 3.12.13, with override-dependencies = ["fastapi==0.141.1"] in place, an agent served through the AG-UI connector completed a full round trip: tool calls, an ACTIVITY_SNAPSHOT carrying a2ui_operations, and RUN_FINISHED. I saw no incompatibility. That is one round trip on one version, so it is a weak signal on its own. It is worth stating because it is consistent with a stale bound rather than a protective one.

Why I do not expect this to correct itself. .github/workflows/python-dependency-maintenance.yml runs weekly, and sets DEPENDENCY_RELEASE_CUTOFF to seven days before the run. _dependency_bounds_upper_impl.py applies that as an exclude_newer filter, so a candidate soaks for a week before it becomes eligible. fastapi 0.141.1 has been eligible since roughly 2026-08-05. The scheduled runs on Aug 10, Aug 17, Aug 24 and Aug 31 all concluded successfully, and the AG-UI bound did not move across releases 1.1.0, 1.2.0, 1.2.1 and 1.2.2. I may be misreading the workflow, and I would welcome a correction.

Two things would help consumers either way. If the bound is protective, saying so in the release notes would turn a bare resolver error into a decision a reader can make. If the bound is conservative, raising it removes an override from every downstream project that runs a current fastapi.

Thank you for looking at it.

[BenTaylorDev]

For disclosure: I work on CopilotKit, which maintains the AG-UI protocol that this connector implements. We hit this in our own onboarding evaluation, where a project on a current fastapi adds the connector.

Happy to test any candidate range against that path if it helps.

[manjunathshiva]

Your reading is right, and the part you could not see from the outside is that the automation which would have raised this bound has not run since 2026-07-27.

The ceiling is not protective. It is residue from the #7339 false conflict, exactly as you suspected. I ran the project's own upper-bound optimizer against main, scoped to this pair:

$ uv run python -m scripts.dependencies._dependency_bounds_upper_impl \
      --packages ag-ui --dependencies fastapi --dry-run
packages\ag-ui (agent-framework-ag-ui) :: fastapi :: baseline current_lower (lowest-direct) [0.121.0]
packages\ag-ui (agent-framework-ag-ui) :: fastapi :: baseline current_upper (highest)       [0.139.2]
packages\ag-ui (agent-framework-ag-ui) :: fastapi -> <0.142.0 (probe 0.141.1)

Each of those lines is a real probe: an isolated environment at that fastapi version running AG-UI's full Pyright pass and its complete test suite. fastapi 0.141.1 passes both. Nothing found a fastapi incompatibility, because there is not one to find.

That result also answers the conditional you posed. You wrote that raising the bound needs either the siblings to move off <0.138.1, or #7342's probe isolation to extend far enough that AG-UI stops inheriting their ceiling. The second already happened. Under current main, AG-UI's probe closure is {core, orchestrations} — DevUI is not in it, its fastapi<0.138.1 no longer reaches the probe, and the resolve you see in #7339 does not recur. #7342 fixed the mechanism; it just hand-set the ceiling to <0.140.0 on the way past, and nothing has revisited it since.

On "why I do not expect this to correct itself" — you were right, for a reason that is not visible externally. Your exclude_newer analysis is accurate and fastapi 0.141.1 has indeed been eligible since ~2026-08-05, so that is not the blocker. The blocker is that the step which would apply it never executed. Run dependency upper-bound validation is gated on if: steps.validate_bounds_test.outcome == 'success', and the preceding step carries continue-on-error: true — which maps its conclusion to success (that is the green run you observed) while leaving its outcome at failure. So:

Date	Run	Run dependency upper-bound validation
2026-07-27	30239325494	success — last time it ran
2026-08-03	30786524929	skipped
2026-08-10	31355767987	skipped
2026-08-17	31993805435	skipped
2026-08-24	32689375667	skipped
2026-08-31	33356153685	skipped

The four green runs you cite are green in exactly the way you were skeptical of. The last one that actually validated anything was two days before fastapi 0.141.1 shipped, which is why the ceiling stops where it does. This is not specific to AG-UI — every package's bounds have been frozen for five weeks.

The underlying failure is unrelated to fastapi: packages/anthropic type-checks against a google.auth.credentials that its isolated probe does not install, and the gate aborts there before reaching anything else. Since the gate stops at the first failure, I probed all 35 packages individually to see what else was hiding behind it — six fail, not one. Two are probe artifacts of that same kind and I am fixing them; the other four are real defects the gate existed to catch, including two packages that under-declare a runtime dependency. So the honest answer on timing is that restoring this will take more than one patch. I have filed all of it separately as #8049 rather than bundling it here, since it is a different topic from your question.

What this means for your project. The override-dependencies workaround is sound in the meantime, and your round trip on 0.141.1 is consistent with everything above. One correction to aim it better: for a consumer installing both packages, DevUI is the binding constraint, not AG-UI — agent-framework-devui declares fastapi>=0.115.0,<0.138.1 as a runtime dependency, which is why your case 3 lands on 0.138.0 rather than 0.139.2. (hosting-responses declares fastapi only under [dependency-groups] test, so it never constrains consumers — it is not part of your problem.) Lifting AG-UI alone would not free a project that also installs DevUI.

I am deliberately not hand-raising the bound in my PR. Once the gate is restored, --mode upper is the component designed to choose and validate these ceilings, and it has now demonstrated on the record above what it will pick. The bound value is a maintainer policy call; getting the machinery that maintains it running again is the part I can fix.

Thanks for the report — the resolves, the version archaeology and the exclude_newer reasoning made this much faster to run down, and your offer to test a candidate range may be worth taking up once the ceiling moves.

[github-actions]

🤖 Automated triage reproduction notes (agent-authored — trust but verify)

Agent analysis

The bug is in python/packages/ag-ui/pyproject.toml:27, where fastapi>=0.121.0,<0.140.0 excludes validated FastAPI 0.141.x releases. It triggers whenever a consumer resolves agent-framework-ag-ui==1.2.2 with fastapi==0.141.1; minimally, place both requirements in a file and run uv pip compile requirements.in --python-version 3.12.

• Failing test: python/packages/ag-ui/tests/ag_ui/test_dependency_bounds.py
• Files examined: python/packages/ag-ui/pyproject.toml, python/packages/devui/pyproject.toml, python/packages/hosting-responses/pyproject.toml, .github/workflows/python-dependency-maintenance.yml, python/scripts/dependencies/_dependency_bounds_upper_impl.py
• Tests run: uv pip compile AG-UI with FastAPI 0.141.1, uv pip compile AG-UI alone, uv pip compile AG-UI with DevUI, scoped upper-bound optimizer, python/packages/ag-ui/tests/ag_ui/test_dependency_bounds.py
• Reported version: 1.2.2
• Current version: 1.2.2

[eavanvalkenburg]

Ben Taylor (@BenTaylorDev) thanks, this is intentional for non 1.0 packages, since minor updates before 1.0 might contain breaking changes, we try to keep up, but things move fast, we also have by now added a delay between a new version and adding it to not repeat the LiteLLM issue. We can deviate if we know a package does not add breaking changes before 1.0, but I don't know if that is the case for FastAPI. Let me create a PR to do the upgrade directly.