If you run with AUTO_SELFUPDATE on, this one matters. It affects every release from 2.9.0 to 2.11.0.
I found it in my own log, while @famewolf and @NotRetarded were testing something else entirely on #2: my server had stopped updating anything, and had been quietly refusing for 43 minutes.
The scheduled self-update check takes the shared update lock. The finally that gives it back first reads a flag to see whether the helper container is about to stop the process — and that flag was never set on a real engine, so the read raised AttributeError inside the finally, before the release. The lock stayed held for the life of the process.
Everything after that answered "an update is already running". Tapping a container in the update notification queued it behind a batch that had finished forty minutes earlier, where it waited until the container restarted and the in-memory queue died with it. From the outside it looks fine: the bot answers, the buttons work, the log is clean. Nothing ever updates.
The cause was one line in the wrong place. v2.9.0 added the update queue by inserting three methods into the middle of the engine's constructor, which left the tail of it — including that flag — sitting after a return inside the last of them. Dead code, never run.
Both lines are back where they belong, and neither finally can raise before releasing any more: a lock release must not depend on an attribute lookup succeeding.
No test caught this because every one of them builds its engine with __new__ and sets the two or three attributes it needs by hand. That is a reasonable fixture and also a blind spot the size of the constructor. There is now a test that builds the real thing.
Upgrade and it's gone. If you have been staring at a queued update that never starts, that was this, and restarting the container clears it in the meantime.