The common-HASH.js files contain, among other things, a variant of this code (line breaks added to make it easier to read):

"use strict";
exports.DEVELOPMENT_SERVER=!1,
exports.DATASTORE_REDIS_ARGS={test_database:1,database:0,server:"10.2.2.38:55406",namespace:"MB:"},
exports.RENDERER_PORT="65407",
exports.STATIC_RESOURCES_LOCATION="https://staticbrainz.org/MB",
exports.MB_LANGUAGES="de fr nl en";

The four keys in DATASTORE_REDIS_ARGS appear in random order; there are 4! = 24 possibilities, and each run of compile_resources.sh will randomly choose one; as a consequence, the MD5 hash used in the file name changes, too. Since each frontend Docker container makes its own random choice, there are always multiple almost identical files in use, and a browsing user is likely to see all of them within twenty or so requests. Each time, a new copy of the same JS is stored in the cache.

Is it even necessary to store this information (and also the RENDERER_PORT) in client-side JS? It can’t access Redis or the renderer anyway. If it is necessary, the order of the elements in DATASTORE_REDIS_ARGS needs to be made consistent (e.g. lexicographical order of the keys).

Today, the following variants are in use, with the given key order:

common-03dc105c3a.js: tdb, db, s, nm
common-091757a333.js: s, tdb, db, nm
common-3688eda295.js: nm, tdb, s, db
common-e2de871746.js: s, db, tdb, nm
common-fc164be33a.js: db, nm, tdb, s

beta:
common-d07a1f2171.js: nm, db, s, tdb
common-fb376f4ecd.js: tdb, nm, db, s