Chapter 11 - Worked Answers

1. Running plus pulling

The next pass creates zero tasks. Both current-version tasks are nonterminal and enter current, so effectiveCount is two. Health is not the criterion for this replica deficit calculation. Counting only healthy tasks would recreate work while image pull or initialization was still in flight, potentially growing replicas every iteration. Availability and rollout readiness require their own observations and policy; they should not be silently substituted into this count.

2. A failed task and restart policy

With restart never, the failed current-version task contributes to nonRestartableFailed. One running plus one such failed task produces effectiveCount two and no replacement. With on_failure, the failed task does not enter that special count, so effectiveCount is one and one replacement is created. The policy prevents endless replacement of deliberately non-restartable work. This library count alone is not evidence of retry backoff, a maximum restart budget or execution of the replacement container.

3. What the restart fixture retains

The fixture constructs a new reconciler while retaining the fake store that contains the first controller’s tasks. The new controller can read those same identities and avoid duplicate creation. Deleting or replacing the fake store removes the authoritative input and tests a different scenario. Neither version establishes fresh-process recovery of the default server’s maps. The focused executed suite supports the retained-store controller behavior; database composition and actual host containers remain separate boundaries.

4. Two controllers with the same deficit

Use a barrier fake store so two reconciler instances both finish ListTasksByService with an empty list for desired two before either creates a task. Release both and inspect all created identities and events. Per-task optimistic guards cannot protect creation of previously nonexistent IDs. A globally unique creation claim requires a serialization mechanism covering the deficit read and creates, such as a correctly fenced leader or an appropriate shared transaction/locking protocol. Default NoopLeaderLock is not that mechanism. Define the protocol and test stale ownership before asserting global uniqueness.

These answers distinguish source reasoning from the scoped execution records linked in chapter 11. Proposed changes require separate implementation and validation.