v1.5.1

Fixes a site that has not started since v1.5.0 — and, it turns out, since v1.4.21 before it. Anyone running either of those versions should move to this one.

What was wrong

Every container exited on its first line of work, unable to find a file it imports. "Add replicated persistent folders" added a new module and an import of it, but the runtime image is assembled from a list of files named one by one — deliberately, since everything else in the source tree is client code already compiled into the bundle — and the new module was never added to that list. So the image was built without a file it needs.

Running the published images side by side confirmed it rather than inferring it: v1.4.20 comes up healthy, v1.4.21 and v1.5.0 both exit immediately with the identical error, and v1.4.21 is the first release containing the change that introduced it.

Why nothing caught it

The build succeeded. So did the push, and the release. The failure only appeared where it costs the site — and with a hand-maintained list of files, the next import added to a file already on that list would have done exactly the same thing again.

So the build now does the same work the container does on its first line: it resolves the whole set of modules the server reaches, and fails if one of them is not in the image. A missing file now costs minutes of build time instead of taking the site down. Proved in both directions — the build passes with the file listed, and fails with a named error when it is removed again.

Verified end to end: an image built from this release comes up healthy and serves the landing page, the marketing pages, the login page and the health check, with unknown paths still answering 404.