Improvement: When a container update fails, the container should return to the update available list immediately

[begunfx]

Current behavior as of rc.26 seems to be if a container update fails it doesn't return to the update available list so the user is unabl to try again. If my assumptions are correct, please consider changing this behavior. Thanks!

[flederohr]

I had a similar experience and opend following issue for it #391

[scttbnsn]

Thanks for the report (and the cross-reference to #391).

There are two distinct cases worth separating:

Pull failure (the new image couldn't be downloaded) — the container already returns to the update-available list on the next watch cycle. No change needed there.

Replacement failure (the image pulled, but recreating the container failed — e.g. the pulled image isn't available for your host's CPU architecture) — this was the case in #391 where the old container could be lost. That's now fixed for the next release candidate (v1.5.0-rc.29):

• a pre-flight check verifies the pulled image is architecture-compatible with the host and aborts before removing the old container if it isn't, and
• if a recreate still fails for any other reason, the original container is restored from its saved spec rather than left destroyed.

So a container that fails to update stays running on its current version and remains visible as update-available, instead of disappearing.

[scttbnsn]

Hey @begunfx, circling back to make sure this is properly closed out.

The container does return to the update-available list immediately after a failed update in all three cases. The way it works: the "update available" state is a computed property that reads only the container's current image digest and the last scan result. The update execution path never touches those fields, so a failure can't clear the flag. The active-operation lock clears the instant the failure status is written, so there's no wait for the next cron tick either.

The one place retry isn't a one-click thing: if the Docker trigger pulls a new image, removes your container, tries to recreate it, and that fails but the rollback to your old container succeeds, we intentionally block a retry of the exact same image digest. Letting you immediately re-hammer the same failed image would just loop: pull, create-fail, rollback, pull, create-fail, rollback. The container shows in the list with a badge explaining why the button is disabled. That gate lifts automatically the next time the watcher scan sees a genuinely newer image, or you can override it right now with dd.update.rollback-gate=off on the container.

For pull failures (image couldn't be fetched at all) or failures where the rollback itself also fails, there's no gate, retry is immediate.

Separately, the related case @flederohr linked (#391, where a failed Compose update could leave the service with no running container at all) is fixed and shipped since v1.5.0-rc.29: there's now an architecture pre-flight check that aborts before removing the old container, plus a restore-from-spec safety net if the recreate fails. That issue is closed.

Does that cover what you were after, or were you specifically looking for auto-retry of the same failed image target?