Chapter 9 - Worked Answers

1. A stale task claim

AssignTask predicates on task ID, expected UpdatedAt and actual_status pending. After the first writer updates that row, the second writer holding the old token cannot match the same pending snapshot. A subsequent scan with no returned row becomes ErrConflict. Although row_version increments, the shown WHERE clause does not compare it, so its presence alone cannot explain the concurrency guard. Read the actual winner as well: two rejected requests would not establish progress. The separate full-schema experiment observed one winner and one conflict; the untouched upstream fixture failed earlier because its migration list was incomplete.

2. Escaping the transaction

The callback must use its transaction-scoped store argument. A closure can still call a captured outer pool-backed store; lexical nesting does not change which connection executes SQL. That outer call can commit independently even if the callback later returns an error. The generic WithTx fallback also executes directly when its candidate does not implement Transactor. Therefore identify the concrete candidate and trace every relevant mutation and strict event through the scoped argument. A Docker call cannot be rolled back by returning a PostgreSQL error; external effects require reconciliation or an explicitly designed protocol.

3. A fixture/schema mismatch

The observed SQLSTATE42703 failures mean current node SQL selected agent_version from a schema without that column. The upstream reset helper applies migrations 000001–000014; agent_version is added by 000016_operations_safety.up.sql. Preserve those failures as baseline evidence. In a separately named teaching fixture, apply all 16 migrations to an owned disposable database, create one pending task, give two writers its same UpdatedAt, and assert one success, one conflict and a coherent stored assignment. That exact separate experiment passed in the recorded full-schema fixture; it does not rewrite the upstream test result.

4. Durable composition evidence

Inventory every API state and ownership relationship, including jobs or notification sinks, whose interfaces are not embedded in the composite Store. Persist intent, identities, credentials/secret references and operation history with defined transaction boundaries. Start an application instance, record Atlas service/task identity, terminate it, construct a new process against the same database, and verify restored API state and subsequent reconciliation. Reusing one fake store or MemoryService object only tests controller reconstruction. Also test schema compatibility, failed side-effect recovery and secret-key requirements. A constructor change alone neither supplies missing methods nor proves safe restart behavior.

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