A Docker update started the replacement, slept 5s and inspected it.
Docker reports health "starting" until the first probe completes, which
with the default 30s interval is long after that, so the agent almost
never saw "unhealthy" and its rollback for an unhealthy replacement did
not fire. The server then classified the "starting" readback as
postcondition_contradicted, so nearly every update of a health-checked
container showed "Outcome contradicted" even when it came up healthy.
Fleet telemetry shows unverified update failures rising from the
release that added the strict readback rule.
The agent now polls a running replacement whose health is "starting"
every 2s for at most 3 minutes, then applies the existing crash and
unhealthy checks to the latest inspect, so an unhealthy or exited
replacement rolls back. A restarting replacement also counts as
crashed: Docker keeps Running set while it waits to restart, which let
a crash loop pass. One still starting at the cap is kept.
The server treats a matching running replacement whose health is still
"starting" as inconclusive with container_health_starting, the code
start and restart verification already use, for both the agent readback
and the independent daemon observation.
rcourtman
7045d6f6e1