Let's consider situation when application is running and is healthy. Let the deployment be scheduled. New version of app cannot be started (for whatever) reason. Then user delete the deployments (by clicking rollback in UI or just sending DELETE on endpoint without force). Let assume that app cannot be redeployed (e.g. artifact is unavailable). After this procedure user end up with 0 running instances!
1. resource we can control is an URL of http server accesible from mesos agents that we can start/stop on demand (e.g. python -m SimpleHTTPServer on local machine)
2. Deploy application
3. Update this application
4. Application is failing.
5. Disable resource we can control.
6. Rollback to previous version.
7. We end up with 0 running tasks.
IMO when user want to rollback deployment, expected behavior will be to do not restart currently running application if has same version as version we want to rollback. Or behave as normal deployment and take in to account upgradeStrategy settings.