Undocumented breaking change in 0.36.0 (config.setup_event_loop missing)

[semohr]

I just tried updating, and it looks like between versions 0.34.3 and 0.36.0 a breaking change was introduced: config.setup_event_loop is no longer available.

I realize the project is still below version 1.0, but please keep in mind that downstream users may rely on publicly exposed functions. Removing them without notice can cause unexpected breakage.

It would be very helpful if such changes were documented in the changelog, or, since you’re following semver, released as a major version increment instead.

For anyone having the same issue it was renamed: setup_event_loop -> get_loop_factory

[aylei]

For those downstream packages that do not pin uvicorn (I have one), all published versions of them will be affected. I am wondering can we add setup_event_loop back, mark it as deprecated and release a 0.36.1?

[Kludex]

How were you using setup_event_loop?

[semohr]

Using a deprecation warning is pretty common imo. You could always add one 👍 One has to remember to remove the deprecation at some point tho.

I’m not sure how these things are handled in uvicorn, so I don’t want to impose.

[Kludex]

I think the problem here is not this change, it's that is not clear to the users what is a public API here and the guarantees about them.

That method was never supposed to be used, even if it doesn't have a leading underscore. If it's not documented, it's not public facing.

---

That said, I understand the annoyance. I don't really want to yank it, and adding a backwards compatibility solution would take too long. Did you folks use it only for testing?

I think we can document in the release notes?

[Kludex]

How were you relying on that method?

[semohr]

We are starting a server in a test environment to run integration tests against our api. I'm not too sure why this was added in the first place but we had the setup_event_loop call for some years and it was added with the initial TestSetup commit.

Although it seems that the call overall is not required anymore. Removing it does not seem to have any impact.

Just did a quick stackoverflow search and our setup is similar to: https://stackoverflow.com/a/64454876

[Kludex]

Just did a quick stackoverflow search and our setup is similar to: stackoverflow.com/a/64454876

Which doesn't seem to be working as expected in previous versions as well... 👀

Although it seems that the call overall is not required anymore. Removing it does not seem to have any impact.

Yeah, you should be fine.

[Kludex]

I've implemented this: http://github.com/Kludex/uvicorn/pull/2709, just to point people to this discussion.

[time-less-ness]

Skypilot API server was using this private method and were apparently caught off-guard with the change, since now the API server is crashing for me.

[danoctua]

uvicorn-worker is also using the same API and is not pinning the version, which broke some gunicorn + uvicorn worker integrations

https://github.com/Kludex/uvicorn-worker
The latest fix, however, addresses it: Kludex/uvicorn-worker@c6019eb#diff-4df083912aa5bfe6743be58b79c56be0fd12979fd692f7d125e02e7b580964c3R123-R126

[ropable]

We were bitten by this change (not in production, happily) because we were making use of uvicorn-worker to run the ASGI application service. The solution in our case was to upgrade uvicorn-worker from 0.3.0 to 0.4.0 (which we initially failed to do when upgrading uvicorn to 0.36.0).

[rijenkii]

Running pip install uvicorn-worker==0.3.0 without explicitly installing uvicorn now does not work at all, as pip will install the latest version of uvicorn that is incompatible with the selected version of uvicorn-worker.

[Kludex]

Bump uvicorn-worker.