Currently, when static assets are deployed via scap out-of-sync with mediawiki version bumps, there's no mechanism to invalidate previously-cached copies of the old data that lived at that URL. What saves us in the most common case is that most of those assets are loaded by ResourceLoader rather than directly by the client, but this isn't true for all such paths (such as certain icons/images, some of which have cache-busting workarounds now like ?date query args), and it's not true for ResourceLoader under debug=true, either.

What we need here is a mechanism for scaps which change such files mid-version to send HTCP invalidations for these paths to the cache clusters, and there are various implementation details to sort out there. Probably the key one to solve up front is to research what the HTCP request should look like to ban a /static/ path across all hostnames, given the custom vcl_hash stuff that caches them centrally for all hostnames. That may require some VCL implementation on our end as well.

While this problem has always been present, the recent migration of these URLs from the bits cluster to the text cluster has magnified its visibility, because the old bits clusters had a small enough cache that they would eventually lose track of outdated files organically much faster than the text clusters do.