Rapids Updates Always Land, and Startup Work Runs Once
Changes sent during a rollout are never dropped, a rollout only counts as done once its own revision is ready, and two new settings stop startup work such as migrations from running twice.
What's changed
- An update sent while a rollout is still running is queued and applied next instead of being silently dropped, and several quick changes roll out together
- Your change reads as queued until its rollout starts, and a rollout counts as finished only once its own new revision is ready, so danube rapids update --wait (CLI 1.3.0 or later) returns only when your change is live
- A rollout whose new revision never appears now fails after 20 minutes with a clear message instead of staying in Deploying
- Retrying a rollout no longer creates an extra revision, so startup work does not run again
- New Initial scale and Scale-down delay settings, under Resources and scaling in the Advanced section and in the API and CLI, let a container that migrates on boot avoid doing that work on two revisions at once
- Deployment history no longer marks healthy older revisions as failed, and health alerts skip retired revisions and name the image you actually deployed