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.