Problem

You shipped a hotfix and the deploy reported success, but users still see the OLD behavior. The web container is Up and healthy — and docker ps shows it running myapp:latest, which looks current. Yet GET /version still returns 1.7.2 (the old build). Prove what image web is actually running and get it onto the current :latest.

Initial setup

• web — shows myapp:latest in docker ps, Up 6 hours, serving 1.7.2.
• myapp:latest was rebuilt during the deploy (it now points to a new image).

Example interaction

$ docker ps --format '{{.Names}}  {{.Image}}'
web  myapp:latest

$ docker inspect web --format '{{.Config.Image}}'   # tag REQUESTED
myapp:latest
$ docker inspect web --format '{{.Image}}'          # sha PINNED at run
sha256:a17e5d3c9b82...
$ docker inspect myapp:latest --format '{{.Id}}'    # what :latest is NOW
sha256:d5208f2801ce...

The container's pinned sha and the tag's current sha don't match — the tag moved, the container didn't.

Acceptance

You've solved it when:

• You've shown web is running a stale image: its pinned .Image sha

(sha256:a17e5d3c..., which docker images maps to myapp:1.7.2) does NOT equal the current docker inspect myapp:latest .Id (sha256:d5208f...) — i.e. :latest drifted, the container kept its old sha. NOT misdiagnosed as a build/registry bug or app cache.

• You've recreated web against the current tag (`docker rm -f web &&

docker run -d --name web -p 8080:8080 myapp:latest) so its .Image` now equals myapp:latest's .Id and it's running the new build.

Constraints

• Tools: docker CLI only.
• docker restart web does NOT help — it restarts the same pinned sha.

Only rm + run (or compose up --force-recreate) repins the tag.

• Trust the sha, not the IMAGE/.Config.Image tag column — both show the

tag name and look current even when the pinned sha is stale.

Follow-up

1. Why does docker restart keep the old code but docker rm + docker run

fix it?

1. Why is :latest a mutable pointer, and what tagging scheme (git-SHA /

semver digests) prevents this class of incident?

1. In compose, why can docker compose up reuse a stale local :latest

unless you pull / set pull_policy: always?