Chapter 12 - Worked Answers

1. Invocation versus object identity

The fake operation recorder can log two CreateContainer calls while the implementation returns one existing container identity. Idempotency concerns the resulting managed object set, not the number of method invocations. Assert that both results identify the same task-owned container and that the managed container set has not grown. A matching image name alone is insufficient ownership evidence. At the Engine adapter boundary, task-ID lookup and create-conflict recovery are narrower than a complete desired-spec comparison.

2. Uncertain inspection

Propagate or record the daemon transport error and avoid treating it as proof of absence. Creating or removing based on an unavailable inspection can duplicate work or damage a still-running container. Not-found has explicit semantics; a disconnected socket or server error does not. A safe fixture should inject these outcomes separately and assert no destructive operation for the uncertain case. A later successful observation can drive convergence without rewriting the original failure as a clean absence.

3. An unrelated recorded ID

The task record is a hint about runtime identity, not authority to delete any referenced object. The agent inspects ownership metadata and requires the managed marker plus matching node/task identity before removal. A nonmanaged container fails that predicate even if the task’s ContainerID points at it. The focused tests passed the nonmanaged protection scenario using fakes. They do not authorize deleting arbitrary containers on a real host; an owned-daemon repetition must inventory exact run resources and preserve unrelated objects.

4. Lost acknowledgement adoption

On an isolated daemon, deploy one Atlas task, arrange for its created report response to be lost after server acceptance, and retain the real task/container IDs and managed labels. Reconcile again and verify that the same suitable container is adopted rather than another object being created. Record actual reports, Engine object count and IDs before cleanup. This demonstrates recovery across that specific acknowledgement window. It does not establish default-server durability: a new server process loses its memory-owned task inventory unless a separate durable composition restores it.

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