Learn through experiments

Make automation safe to retry

What if a charge succeeds but its response is lost?

Entering midway? Revisit Test the whole input contract for the preceding worked example, or start here and use the explanation below.

1 · Try

Start with a concrete question

A fictional local service records a charge and may lose its response. Retry limits and a simulated idempotency key determine whether duplicates occur.

Try the initial inputs, then write a prediction before changing one setting. All calculations run locally on your CPU.

Go directly to the experiment · Review basic mathematics

2 · Predict

What do you expect?

Predict whether a timeout means no charge happened.

Your prediction and reason

3 · Experiment

Change one thing. Inspect what happens.

Lose the first response and retry without a key; compare calls, charges and receipts.
Reuse the key and repeat.
Set persistent failure and verify the attempt cap. Implement the local state machine in the code runner.

Experiment inputs

Additional retry limit 1 Reuse idempotency key 0 Fault: 0 none, 1 first response lost, 2 persistent pre-execution failure 1

Inputs
Your settingsMechanism
Calculation belowEvidence
Compare outcomes

Calls made2

Charges recorded2

Confirmed success1

Duplicate charges1

Compare the current results

Every bar starts at zero and uses the same numeric scale in this chart. The upper bound automatically adjusts to the largest current value (at least 1), so compare the numbers when changing inputs. Units and quantities come from each label; different kinds of quantity are not interchangeable. Displayed values are rounded to at most six significant digits.

Calls2
Actual charges2

Follow the calculation

Attempt 1: server records charge; response lost.
Attempt 2: server records charge; receipt received.

A lost response does not prove an operation failed. Reuse an idempotency key for retries; bound attempts and surface unresolved outcomes.

Implement a bounded retry state machine

The first response is lost after the charge. Add a guard so retrying the same operation does not charge twice. Expected final output is calls 2, charges 1, confirmed true. Change loseFirst to false and test again. This local state is only a simulation of a durable server-side receipt.

Your program

317/8,000 characters. Drafts save locally and are included in backups. Importing or opening a draft never runs it.

Bounded JavaScript subset: variables, primitive arrays, conditions, loops, functions and print. No browser objects, network, imports or eval. Maximum 10,000 operations, 64 array items, call depth 16, strings of 256 characters, 40 output lines / 4,000 output characters and 160 trace frames.

Compare with my earlier draft

const retries = 2;
const loseFirst = true;
let calls = 0;
let charges = 0;
let confirmed = false;
for (let attempt = 0; attempt <= retries; attempt++) {
  if (!confirmed) {
    calls += 1;
    charges += 1;
    if (!loseFirst || attempt > 0) { confirmed = true; }
  }
}
print(calls);
print(charges);
print(confirmed);

Explain what you changed and why in your observation notes. Text differences do not establish quality.

Inspect an example solution after your attempt

const retries = 2;
const loseFirst = true;
let calls = 0;
let charges = 0;
let confirmed = false;
for (let attempt = 0; attempt <= retries; attempt++) {
  if (!confirmed) {
    calls += 1;
    if (charges === 0) { charges += 1; }
    if (!loseFirst || attempt > 0) { confirmed = true; }
  }
}
print(calls);
print(charges);
print(confirmed);

This is one worked example. Test another input and explain its limitations.

What changed, what stayed fixed, and what does the evidence support?

Captures keep your inputs, prediction and observation. Results are recalculated from those inputs. Resetting inputs keeps your captures and challenge history.

4 · Understand

Explain the mechanism

Make automation safe to retry

A fictional local service records a charge and may lose its response. Retry limits and a simulated idempotency key determine whether duplicates occur.

Predict before changing inputs

Predict whether a timeout means no charge happened.

Understand the mechanism

A request and its response are separate events. A missing response can leave the caller uncertain even though the operation completed.

With one retry after a lost response, two calls create two charges without deduplication. A reused operation key lets the second call return the earlier receipt instead.

Bound retries, record outcome uncertainty and distinguish a failed operation from an unconfirmed result. Idempotency must be implemented by the operation owner, not merely by naming a variable.

Calculate it yourself

Maximum calls = 1 + retry limit. A reused operation key applies a charge at most once in this fixture.

Guided investigation

Lose the first response and retry without a key; compare calls, charges and receipts.
Reuse the key and repeat.
Set persistent failure and verify the attempt cap. Implement the local state machine in the code runner.

Assumptions and limitations

A synchronous local simulation, not an actual payment service or distributed transaction guarantee.
Concurrent requests, key expiry, durable storage and backoff timing are outside the model.

Further investigations

High school: Diagram request, action and receipt as three distinct events.

College: Implement a bounded state machine and tests for success, lost response and permanent failure.

Working professionals: Write an automation runbook with idempotency, monitoring and unresolved-outcome escalation.

Your implementation or data task

Use the editable workspace on this page. Its output is practice evidence; explain why it satisfies the contract and test a fresh case.

5 · Apply

Try a fresh case

An operation permits three additional retries and every attempt fails before execution. What is the maximum number of calls?

Your numerical answer

This is a public practice check. Retries support learning; matching a number does not certify independent proficiency.

Take the investigation further

Choose any extension. These are project prompts for you to carry out; they are not automatically assessed.

School investigation

Diagram request, action and receipt as three distinct events.

College investigation

Implement a bounded state machine and tests for success, lost response and permanent failure.

Workplace investigation

Write an automation runbook with idempotency, monitoring and unresolved-outcome escalation.

6 · Continue

Keep the evidence, choose your next step

Completion records your own decision that you have worked through this investigation. Practice checks and independent project evidence are separate.