Yesterday's update to anyio breaks startlette

[fernandosilveira]

Yesterday anyio updated to version 4.0.0 and starlette accepts anything >=3.4.0.

Apparently, the latest anyio no longer has start_blocking_portal, thus breaking the test client (e.g., here).

I haven't looked deep enough into it but I suppose it's reasonable that anyio did not feel obliged to maintain backwards compatibility on a major version upgrade.

[Kludex]

Issue created for it: #2262.

Thanks for reporting it.

[agronholm]

You say "breaks starlette" but offer no proof. I personally tested AnyIO 4 against starlette's test suite before making the release, and apart from one line coverage miss, everything worked fine.

Why do you claim that AnyIO no longer has start_blocking_portal? Sure, you have to import it from anyio.from_thread now, just like the test client code you linked to does!

[agronholm]

My recommendation for you is to see if you can upgrade FastAPI to the latest release which appears to be mostly compatible. Meanwhile I'm trying to persuade the author to upgrade FastAPI's pinned Starlette dependency.

[VictorBancho]

Hi @agronholm, it seems the latest version of anyio (4.0.0) also enforces the ExceptionGroup paradigm (which can result in breaking changes). Since Starlette 0.19.0 (March last year) the starlette dependency for anyio has been set as >=3.4.0, <5.0.0 which covers two major versions. I assume it was set like this for dev purposes to integrate anyio 4.x? I see your point about locking transitive dependencies, and is certainly valid and something I will incorporate in future.

I wanted to ask, is the ExceptionGroup enforcement a desired consequence of integrating with anyio 4.x? And if so, is this what Starlette deems the new best practice in exception handling?

[agronholm]

I wanted to ask, is the ExceptionGroup enforcement a desired consequence of integrating with anyio 4.x? And if so, is this what Starlette deems the new best practice in exception handling?

The new semantics of task groups always raising exception groups from them is in line with how asyncio.TaskGroup works, and how Trio nurseries work when strict_exception_groups=True is set (which will be the default in the future). I cannot speak for the Starlette devs regarding their best practices.

[agronholm]

I added code in Starlette 0.31 (I think?) that extracts a single exception out of a single-exception group, so as to restore compatibility. But that doesn't help FastAPI users who are still stuck with an old Starlette version.

[Kludex]

The problem was that I changed the pinning on AnyIO to allow version 4 when it didn't have the ExceptionGroup changes. At the time I think the idea was to have a release soon, but things got postponed, and we didn't restrict the range.

There's nothing to do now. The recommendation is to always pin your transitive dependencies, and I'm sorry for the inconvenience.

Latest starlette works as expected.