Repository navigation
Python: [Bug]: agent-framework-ag-ui caps fastapi<0.140.0, which excludes every current release #8042
Description
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:
- A project already on a current
fastapicannot add the AG-UI connector at all. The resolve is unsatisfiable. - A fresh install of the connector holds the project at
fastapi0.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.
Metadata
Metadata
Labels
Type
Projects
- Status
Activity
BenTaylorDev commentedon Sep 3, 2026
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
fastapiadds the connector.Happy to test any candidate range against that path if it helps.
manjunathshiva commentedon Sep 4, 2026
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:Each of those lines is a real probe: an isolated environment at that
fastapiversion running AG-UI's full Pyright pass and its complete test suite.fastapi0.141.1 passes both. Nothing found afastapiincompatibility, 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 currentmain, AG-UI's probe closure is{core, orchestrations}— DevUI is not in it, itsfastapi<0.138.1no 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.0on 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_neweranalysis is accurate andfastapi0.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 validationis gated onif: steps.validate_bounds_test.outcome == 'success', and the preceding step carriescontinue-on-error: true— which maps its conclusion to success (that is the green run you observed) while leaving its outcome at failure. So:Run dependency upper-bound validationThe 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
fastapi0.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/anthropictype-checks against agoogle.auth.credentialsthat 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-dependenciesworkaround 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-devuideclaresfastapi>=0.115.0,<0.138.1as a runtime dependency, which is why your case 3 lands on 0.138.0 rather than 0.139.2. (hosting-responsesdeclares 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 upperis 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_newerreasoning 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 commentedon Sep 4, 2026
🤖 Automated triage reproduction notes (agent-authored — trust but verify)
Agent analysis
The bug is in
python/packages/ag-ui/pyproject.toml:27, wherefastapi>=0.121.0,<0.140.0excludes validated FastAPI 0.141.x releases. It triggers whenever a consumer resolvesagent-framework-ag-ui==1.2.2withfastapi==0.141.1; minimally, place both requirements in a file and runuv pip compile requirements.in --python-version 3.12.python/packages/ag-ui/tests/ag_ui/test_dependency_bounds.py1.2.21.2.2eavanvalkenburg commentedon Sep 4, 2026
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.