Docker daemon reports 'version mismatch' after failed upgrade and does not roll back automatically

Goal: assess whether Docker Engine should initiate an automatic rollback when a daemon upgrade fails due to a version‑mismatch error.

Constraints: the current behavior requires manual intervention, which can delay recovery and, in a Swarm cluster, jeopardize quorum if a manager node remains offline. There is no documented policy defining the conditions under which a retry should be attempted versus a rollback, nor any mechanism for the daemon to communicate rollback readiness to orchestration tools.

Uncertainty: it is unclear what safety checks (e.g., binary availability, container compatibility) must be satisfied before an automatic rollback is triggered, and how such a rollback would interact with ongoing workloads or Swarm state.

Questions: What specific criteria should trigger an automatic rollback after a version‑mismatch failure? How should the daemon signal rollback completion to Swarm or Kubernetes control planes? Should a manual downgrade be followed by an automated safe‑rejoin procedure for manager nodes?