Elements of Scalable Web Development
All starting points

Establish · Optional exploration

Challenge an explanation

An agent says a recorder prevents duplicate events after restart. Predict the behavior and test its claim.

Think it through with your agent

Give your agent this URL. It contains the scenario and guidance to ask one question at a time. Start with your own prediction or explanation, then check it against the book.

Read the agent starting point

Use with your task. Establish the evidence baseline. Keep discoveries in your existing evidence or learning notes.

Follow the argument. Test an explanation against behavior.

Read the exercise

Scenario#

An explanation and a quiz produced from it can share the same missing assumption. Use this invented fixture to check a claim independently, extending the review-evidence exercise. Start with an empty store and one newly created recorder. All calls are sequential and concern the same authorized workspace and unchanged payload. Assume appendEvent adds a new durable event on every call, without its own duplicate check; stored events survive a worker restart.

function makeRecorder(appendEvent) {
  const completed = new Set();

  return async function record(requestId) {
    if (completed.has(requestId)) return;
    await appendEvent(requestId);
    completed.add(requestId);
  };
}

Suppose an agent explains this code as follows; the explanation deliberately overstates its guarantee:

After a request completes, its identifier is remembered. Retrying with the same identifier cannot append another event, including after a worker restart.

Investigate#

  1. Before running anything or requesting help, predict the stored event count after each step: call record("C7"), repeat it on the same recorder, then restart the worker and retry C7 with a newly created recorder sharing the existing store. Identify which part of the explanation each prediction tests.
  2. Trace the state on paper or run a small check against the fixture. A test list that survives recreating the recorder can stand in for the store; this simulates losing process-local state, rather than reproducing a complete production restart. Check the stored events independently of the explanation or any generated quiz answer key.
  3. Identify the lifetime and owner of each relevant state value, then rewrite the claim with the narrowest conditions supported by the code. Explain what must change to support the original restart guarantee; Appendix C's state-placement audit develops the durable effect and retry-key boundary.
  4. In a later session, without the agent or explanation, predict what happens if the retry instead reaches a second worker with its own fresh recorder and the same store. Record any change in your reasoning in the existing learning notes.
Show worked reasoning

The counts are one, one, then two. The completed identifiers belong to one recorder's in-memory set; the durable events belong to the shared store. Recreating the recorder loses the set while preserving the first event, so the retry appends another. A second worker with a fresh recorder has the same missing knowledge.

The code suppresses sequential retries of a successfully completed request while that recorder retains its set. Supporting retries after restart or across workers requires the authoritative store to enforce the logical command's identity together with its effects. Persisting a key separately from the event can still leave a crash window; concurrent requests and failures during the write require further checks. The exercise establishes a counterexample to the broad explanation and the behavior of these cases, rather than a complete retry-safety proof.

This is optional, ungraded exploration. The course brief defines the required work.