Recover the inspection request without duplicating it

The first write created WO-41

Botie lost the reply to an approved inspection request. Its work-order service may already have created the job. Build recovery around that uncertainty.

BOTIE

The caller saw an unknown outcome, but the matching completed receipt stores WO-41. What should the application do next?

The inputs we are comparing

Intended operation and receiver contract

Same in both cases

{
  "key": "R7-inspect-1",
  "payload": {
    "asset": "P7",
    "operation": "inspect"
  },
  "effect": "write",
  "idempotent": true
}

Authoritative service receipt snapshot

No receipt yet, with an idempotent receiver

[]

The first write completed despite the lost reply

[
  {
    "key": "R7-inspect-1",
    "payload": {
      "asset": "P7",
      "operation": "inspect"
    },
    "status": "completed",
    "result": "WO-41"
  }
]

Observed result of the last attempt

Same in both cases

unknown

Backoff and per-attempt limits

Same in both cases

{
  "base_ms": 200,
  "cap_ms": 1000,
  "jitter_fraction": 0.5,
  "timeout_ms": 500,
  "max_attempts": 3
}

Attempts already started and run clock

Same in both cases

{
  "attempts": 1,
  "now_ms": 1000,
  "deadline_ms": 2500
}

Result for no receipt yet, with an idempotent receiver

{
  "route": "retry same operation key",
  "delay_ms": 100,
  "result": null
}

Choose an explanation to test

Return WO-41 from the matching receiptCreate a new operation key because the first reply was lost

The receiver is still processing the approved operation

This check uses the pieces from “Recover the operation before trying another delivery”.

BOTIE

The receipt for R12-inspect-1 has the correct payload and is pending. The retry window still has room. Predict which action respects work already in flight.

Intended operation and receiver contract: { "key": "R12-inspect-1", "payload": { "asset": "P12", "operation": "inspect" }, "effect": "write", "idempotent": true }
Authoritative service receipt snapshot: [ { "key": "R12-inspect-1", "payload": { "asset": "P12", "operation": "inspect" }, "status": "pending" } ]
Observed result of the last attempt: unknown
Backoff and per-attempt limits: { "base_ms": 300, "cap_ms": 1200, "jitter_fraction": 0.25, "timeout_ms": 400, "max_attempts": 4 }
Attempts already started and run clock: { "attempts": 2, "now_ms": 500, "deadline_ms": 2000 }

What result should your machine produce for this case?

Use a number, text, or an array matching the requested result. For a matrix, put each row in brackets. Saving your prediction runs your current construction on these inputs and checks the earlier examples too.

Build a construction in the workspace above first. This case will test those pieces.

If the receiver forgets operation keys after a day, what should a week-old ambiguous request do before retrying?

Your notes for later. These stay with this journey.

An idempotency guarantee has a scope and retention policy. Keep unresolved outcomes visible when those assumptions no longer hold.

The ledger is a supplied snapshot, not a distributed database. No service is called and no exactly-once execution guarantee is claimed.

Work through the Python challenges →

Continue the courseCan Two of Botie’s Calls Spend the Same Remaining Budget? →

← Can We Safely Use the Answer Botie Returned?