https://upload.wikimedia.org/wikipedia/commons/thumb/c/c7/444_album_cover.png/600px-444_album_cover.png gives:

HTTP/2.0 429 No Reason Phrase
Date: Tue, 04 Jul 2017 21:15:10 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 0
request-date: Tuesday, 04-Jul-2017 21:15:10 GMT
Server: nginx/1.11.13
Cache-Control: no-cache
x-trans-id: tx01d17ae71a24466295f91-00595c055e
x-varnish: 374988952, 995774772
via: 1.1 varnish-v4, 1.1 varnish-v4
Age: 0
x-cache: cp1063 pass, cp1074 pass
x-cache-status: pass
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-analytics: WMF-Last-Access-Global=04-Jul-2017;https=1
x-client-ip: 24.114.81.77
Access-Control-Allow-Origin: *
access-control-expose-headers: Age, Date, Content-Length, Content-Range, X-Content-Duration, X-Cache, X-Varnish
Timing-Allow-Origin: *
X-Firefox-Spdy: h2

Perhaps new rate limitting in thumbor? Or maybe varnish rate limitting.

MediaWiki core's thumbnailing classes usually give an html error on rate limits, and also don't use the 429 error code last time i checked.

[Even if this particular image is subsequently fixed, it should be investigated why there is no friendly html error message returned]

The rate limits in Thumbor are as close to the old Mediawiki ones as they can be, but there are slight differences. Since this request returned nginx as the server, this is a Thumbor rate limit and not a Varnish one (nginx is used as a reverse proxy in front of Thumbor).

Thumbor doesn't support custom error pages by default, but the underlying framework, Tornado, does. I would need to make an upstream change to Thumbor to make that possible, or possibly some monkey patching. I didn't make that a top priority since the Mediawiki error pages for these cases were very crude and cryptic (they had HTML, but I can't say they were always understandable by the average user).

I've filed a task to improve those error pages: T169683: Thumbor should return informative and nice-looking errors I should be able to tackle it this quarter as part of my post-launch quarterly goal for Thumbor.

If you run into 429s often as an end-user, it would be interesting to know your usage pattern to figure out which kind of rate-limiting you ran into (there are at least 3 different kinds if I remember correctly) to potentially increase the limit on the offending rate limiting algorithm.

I think the error mostly helped users distinguish between known situation (like a rate limit hit), and some sort of unknown error, even if they didn't understand the message.