Proactive audit following #35. v1.42.0 fixed Env; the same trap applied to every other Dockerfile instruction that lands in a container's inspect Config. A container's Config is the image's defaults merged with the user's overrides, with no marker saying which is which — so replicating it wholesale pins the OLD image's values onto the NEW one.
Now filtered against the old image's own Config (genuine user overrides are untouched):
- Labels — image
LABELs merged in indistinguishably, so an updated container kept the oldorg.opencontainers.image.versionand went on claiming its previous version (#36). - Healthcheck — a code comment claimed image-default healthchecks never reach
Config.Healthcheck; verified wrong against a live daemon. Self-reinforcing: a new image shipping a repaired healthcheck could never be installed, because the pinned broken one failed the post-update health gate and triggered a rollback. - User — images re-hardening across versions (root → non-root, changed uid) were forced back onto the old user, causing permission errors.
- WorkingDir / StopSignal — relocated app dirs and changed stop signals were overridden by the old image's values.
- Self-update path — built its run args without the v1.42.0 env filter; now uses the same filter as every other path.
Falls back to the previous behaviour whenever the old image can't be inspected.