Runtime & concurrency
Reveal answer and reasoning
Read the current immutable reference, validate and compute a fresh candidate, then publish only if the expected reference is still present. On conflict, retry from a new observation without performing nonrepeatable work during candidate creation. State whether prior references can ever be republished and how version or lifetime rules address that history. Readers should consume the published snapshot rather than mutable fields changed afterward.
Test stale references, value-equal lookalikes, candidate validation, successful publication, and exactly one local post-success action in a bounded fixture. Record actual retries without requiring a scheduler to create a particular count. The wrong design sends a real effect inside the loop or updates another invariant field separately after publication. Durable state-plus-effect requirements need a genuine transactional or idempotent boundary and failure testing; a CAS followed by a local counter cannot close the crash window between memory publication and external delivery.
What a strong answer covers
- Publish one valid immutable candidate against exact identity.
- Keep speculation repeatable and effects explicitly owned.
- Separate local progress from durable effect guarantees.
Common pitfall
Treating successful memory publication as a durable transaction with an external effect.
Follow-up questions
- How would you publish several related fields coherently?
- What if a post-success effect throws or the process exits?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.