Interesting corner case. So what happens is:

The request comes from the caching layer to Swift; from there, our rewrite handler in the pipeline tries to fetch it from Swift itself, and if that 404s, then it forwards it to imagescalers/MediaWiki.

However, since in this case the container doesn't exist, Swift defaults to 401, presumably for security reasons: attackers should not get 404 for missing containers, as this would allow them to brute force container names until they get a 401 (information disclosure).

So the request never gets passed on to imagescalers, and imagescalers never create the containers, so we're essentially deadlocked.

I'm reluctant to also forward 401s to imagescalers. The only solution I can see -other than creating them by hand in the rare cases we add wikis- would be for MediaWiki to be even more smart and create thumb containers when originals are made. I know very little of MediaWiki's Swift architecture though, so I can't speak for the feasibility of this.

I created the en.wv container by hand and it seems to work now; I didn't do the same for the other languages though, in case Aaron or someone else wants to test things.

Confirmed working on en.wv, thanks. As standard operating procedure we should implement whatever the final fix is on all wikis, even ones with local uploads disabled, as they may always change their mind about wanting to enable them.

This seems to be fixed on all wikis now so closing as fixed.

How was this fixed? Aaron, did you create the containers or did you fix MediaWiki to somehow create them? We should note this for next time :)