Track starlette TestClient anyio.abc.BlockingPortal deprecation until the upstream fix (starlette#3498) is released

[seonghobae]

Warning

DeprecationWarning: The anyio.abc.BlockingPortal alias is deprecated, use anyio.from_thread.BlockingPortal instead. emitted from starlette/testclient.py during the offline test suite (pytest -m 'not nim_live'), once per session.

Confirmed facts (2026-09-14)

• Emitter: starlette TestClient (starlette/testclient.py, _PortalFactoryType / portal annotations) via anyio ≥ 4.15, which deprecated the anyio.abc.BlockingPortal alias.
• Upstream fix: testclient imports the deprecated anyio.abc.BlockingPortal alias Kludex/starlette#3497 → PR #3498 "Use anyio.from_thread.BlockingPortal in TestClient", merged 2026-09-05 on master.
• Latest starlette release on PyPI: 1.6.0 (2026-08-08), i.e. the fix is not released yet.
• This repository's hash lock requirements/ci.txt pins starlette==1.3.1 and anyio==4.14.2; with anyio 4.14.x the alias is not deprecated, so CI does not currently emit the warning. A local environment resolved with a newer anyio does.
• fastapi 0.141.1 (locked) allows starlette>=0.46.0, so adopting the fixed release will not require a fastapi change.

Not a code defect in this repository

No suppression, log filtering, or pin-back is applied. The warning cannot be removed here until starlette publishes the fix.

Next action / internal schedule

• Adopt the first starlette release that includes #3498 by regenerating requirements/ci.txt with the documented command (pip-compile --extra=dev --generate-hashes --no-emit-index-url --output-file=requirements/ci.txt --strip-extras pyproject.toml, Python 3.11), then re-run the full offline suite with the anyio alias warning promoted to an error to prove it is gone.
• Next review date: 2026-09-21 (check PyPI for a starlette release > 1.6.0). Internal target for adoption: within 7 days of that release.

Related

• pytest-asyncio asyncio.get_event_loop_policy deprecation on Python 3.14 is tracked by PR test: support Python 3.14 asyncio #38 (pytest-asyncio 1.4) and is not part of this issue.

[seonghobae]

Still unfixed at starlette 1.6.0, and there is a second thing to do when it lands

Checked directly rather than by reading the upstream tracker.

The alias is still in use three minor versions past this repository's pin. With starlette 1.6.0 installed, importing starlette.testclient under warnings.simplefilter("error", DeprecationWarning) raises:

The anyio.abc.BlockingPortal alias is deprecated, use anyio.from_thread.BlockingPortal instead.

Three sites remain in starlette/testclient.py:

line	use
53	_PortalFactoryType = Callable[[], AbstractContextManager[anyio.abc.BlockingPortal]]
380	portal: anyio.abc.BlockingPortal | None = None
423	def _portal_factory(self) -> Generator[anyio.abc.BlockingPortal, None, None]

So the upstream change has not shipped as of 1.6.0, and this issue remains correctly open. It is still the only unattributed warning in the suite: the other warnings are pytest-asyncio's event-loop-policy deprecations, which #38 owns, and the unclosed-database ResourceWarning, which #37 fixes and which I measured going from 266 to zero on that branch.

The part that is easy to miss when the fix does land

requirements/ci.txt pins starlette==1.3.1. The local environment resolving this project's own pyproject.toml ranges installs 1.6.0. So CI is three minor versions behind, and an upstream fix will not reach CI by itself. Closing this will take two steps, not one: the release, and then regenerating the lock.

That is not unique to starlette. 22 of the 55 packages pinned in requirements/ci.txt differ from what the declared ranges currently resolve to, including ruff 0.16.1 against 0.16.7 and pydantic 2.13.4 against 2.13.5.

I am flagging that as context for this issue rather than as a separate one, because it is the mechanism by which this issue stays open even after upstream closes. requirements/ci.txt is occupied by #38, so regenerating it is not something I am doing from here.

Worth stating plainly about my own reports: every "gates pass locally" line I have written on the open pull requests was produced against the resolved set, not the CI lock. CI has agreed each time, and CI is the authority, but the two sets are not identical.