moto: Moto server hangs with the latest version of werkzeug (v2.2.1)

The breakage of werkzeug was a combination of things - werkzeug introduced some bugs, and also exposed some bugs in Moto. The upcoming werkzeug==2.2.2 release should at least stop Moto from hanging, but will still throw 404’s for some calls to Moto.

For now, Moto has pinned the werkzeug-dependency to < 2.2.x until we have time to resolve this completely.

As a debugging note: Some of Moto’s issues can be solved by setting the attribute RegexConverter.part_isolating = False. This will also cause other services to fail, as we only want this attribute for specific services - so we need to find a way to make this service-specific.

There’s no date planned @jakirkham, but somewhere this week. I’d like to wait until we get some positive feedback that the dev-version works as expected… (hint, hint) 🙂

@jakirkham Moto 4.0.8 has now been released.

Looks like that is a bug that was fixed recently. I was on an older version of PIP, pip 20.0.2, and using that exact same setup, PIP always installed the latest version for me:

$ pip install ".[server]"
Processing /.../testproject
Collecting werkzeug>=0.5
  Using cached Werkzeug-2.2.2-py3-none-any.whl (232 kB)
[...]
Successfully built test-pkg
Installing collected packages: werkzeug, test-pkg
Successfully installed test-pkg-1.0 werkzeug-2.2.2

Upgrading PIP to 22.3 fixes this, i.e. it does install werkzeug 2.1.2.

Having said that: I think a longterm fix, where we can use Moto with any werkzeug-version, is almost ready, so I’m going to focus on that instead.

@bblommers Is it possible to consider pinning werkzeug only if the server is used (e.g.: via moto[server] or similar)? I am only using the s3 portion of moto, and as far as I know, werkzeug version is not critical in this case, although moto forces downgrade where other packages in my environment can use latest werkzeug.

Just to note there are a few projects now copying this workaround. Some show up as xref’s in PR ( https://github.com/spulec/moto/pull/5330 ).

Wonder if it makes sense to include this version constraint in moto packages to help users avoid this. Also curious whether this comes down to an upgrade needed in moto or if werkzeug broke something and this should be surfaced as an issue with that project.

Just confirmed this myself in my own CI pipeline. The critical change was between v2.1.2 (works) and v2.2.0 (hangs) of that package. Everything else in my environment was kept the same.