Chapter 15 - Worked Answers

1. Generic events and contextual meaning

The actual fixture returns four task.status events, but their generic message does not encode pulling, created, running and healthy separately. The fixture’s real request sequence supplies those submitted values, and accepted task snapshots provide additional state context. The event count alone therefore cannot prove four particular lifecycle transitions or any Docker execution. The fixture explicitly injects its reports and uses a no-Docker container identifier.

2. Best effort, strict and transactional

Best-effort Emit logs an append error and returns nil. Strict Emit propagates that error to its caller. Only a caller that joins its mutation and strict append in the same effective database transaction can use the error to roll both SQL effects back. Strict append after an independently committed mutation cannot undo the earlier commit. The API’s best-effort audit path is another distinct policy; a successful user response does not imply every audit append succeeded.

3. Duplicate external acceptance

The receiver can accept the first POST while its response is lost. The sender retries the same event payload and the receiver may accept it again. Deduplicate using stable event identity, scoped by the producing system/namespace as needed, and record completed receiver actions atomically with the deduplication decision. An HMAC signature authenticates payload bytes relative to the shared key; it neither encrypts them nor prevents duplicate valid deliveries. The executed fake transport checks retry attempts and selected redaction/signature behavior, not an actual receiver’s deduplication implementation.

4. An empty list after restart

Possible causes include no matching events, the wrong namespace/type/service filter, retention, or loss of MemoryService state in a fresh process. Compare pre-restart captured IDs/timestamps and filters, process identity, retention settings and separately retained audit/log evidence. Empty history alone cannot prove no operations occurred. PostgreSQL event tables do not change the default executable’s storage path. A durable history claim requires actual composition and a fresh-process recovery experiment, not only an implemented store package.

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