← Inside orch contents

Chapter 17 — worked answers

1. One stop

Four available tasks minus one leaves three; desired three minus remaining three gives zero unavailable. A second stop would leave two and violate MaxUnavailable zero. The replacement guard also limits old stops to the one healthy replacement. Both conditions in stopOldTasks matter; surge is a creation ceiling rather than independent authorization to remove.

2. Cohort-specific health

rolloutStateFor calls isAvailable for old tasks, accepting running/healthy, but increments newHealthy only for TaskHealthy. A running target occupies a slot without authorizing replacement. This prevents transferring the old cohort's availability predicate to the new cohort. It still relies on agent reports and does not independently prove routing.

3. Unhealthy is not failed

Only TaskFailed increments newFailed in rolloutStateFor. The agent reports unhealthy at its threshold; MemoryService converts that report to failed only when restartAllowed permits replacement. Otherwise the stored unhealthy target can stall progress until health recovers or an explicit failed report arrives. Observe actual task transitions and the deployment separately; do not infer a failed deployment from one HTTP probe result.

4. Identity survives only with its owner

The same live MemoryService retains activeRollback and returns that deployment on repeat. Capture the operation ID and unchanged version history. A fresh default server has new maps, so the previous ID/history are absent; retry cannot establish that the original reverse transition was resumed. A durable-domain recovery protocol would need different source and process-level evidence.

Return to Chapter 17.