Save state and resume work
Track durable outcomes and design replay-safe steps. This module has 3 lessons and takes about 1h 50m. Each lesson has a practice exercise that runs real Python in your browser and a short quiz.
Start module 14 in the Learning LabResume from a checkpoint
Return the next stage after the completed checkpoint, starting at validated for None. Return done after completed and review for unknown states.
A checkpoint records the last completed stage. After a restart, the workflow should resume unfinished work rather than repeat every stage.
The fixed stage order is validated, drafted, approved, completed. A missing checkpoint starts at validated. Unknown checkpoint names return review.
Only record a stage as complete after its required result is safely stored. In-memory variables are not durable checkpoints.
See it in action
def solve(checkpoint):
steps = ["validated", "drafted", "approved", "completed"]
if checkpoint is None:
return steps[0]
if checkpoint not in steps:
return "review"
index = steps.index(checkpoint) + 1
return steps[index] if index < len(steps) else "done"
print(solve(None))
Only record a stage as complete after its required result is safely stored. In-memory variables are not durable checkpoints.
Choose an idempotency key
Join colon-free event_id and action strings with a colon to make a stable operation key.
Idempotency means repeated requests for the same intended operation do not create extra effects. A stable key helps a provider or database recognise the operation.
Our key joins the event id and action with a colon. The exercise assumes neither value contains a colon. Different actions on one event need different keys.
A key string alone does not prevent duplicates. The receiver must store and enforce uniqueness atomically, with rules for changed request bodies.
See it in action
def solve(event_id, action):
return event_id + ":" + action
print(solve("e1", "draft"))
A key string alone does not prevent duplicates. The receiver must store and enforce uniqueness atomically, with rules for changed request bodies.
Practical: Simulate an operation ledger
Return execute for a missing key, reuse for completed, reconcile for pending, and review for other ledger states.
An operation ledger records whether a key is new, pending, completed, or failed. Completed work can return the stored outcome. Pending work needs reconciliation before another attempt.
This read-only function maps a key state to a next action. It does not reserve keys or write a database. Treat absent keys as execute, completed as reuse, pending as reconcile, and anything else as review.
Concurrent production workers need an atomic reservation, not a separate check followed by an unprotected write. This simulation does not provide exactly-once delivery.
Your experiment plan
Use the browser editor or the notebook. All records and AI responses are fictional. No network calls, credentials, or real messages are used.
- Trace a run that crashes after an external effect but before recording completion.
- Run the example and predict its result before changing it.
- Complete the function in Practice and run the checks. Add your own normal, empty, and failure cases.
- Compare the action for new, pending, completed, and failed keys.
- Save the notebook with your observations and explain one limitation of the simulation.
What to hand in
- A ledger design with reservation, reconciliation, and replay notes.
- A test table with inputs, expected outputs, actual outputs, and one revision.
Reflect on your results
Which guarantee must the external provider support?
The automatic exercise checks the core code behaviour. Review observations and written deliverables yourself or with a mentor.
See it in action
def solve(key, ledger):
if key not in ledger:
return "execute"
if ledger[key] == "completed":
return "reuse"
if ledger[key] == "pending":
return "reconcile"
return "review"
print(solve("e1:draft", {}))
Concurrent production workers need an atomic reservation, not a separate check followed by an unprotected write. This simulation does not provide exactly-once delivery.
Free, open and run by a nonprofit.
This page is part of AI Automation, a free course of 20 modules and 60 lessons in the engineering.fit( ) Learning Lab. The Learning Lab is built and run by engineering.fit( ), a nonprofit founded by Abdullateef Opeyemi Bakare that helps African engineering students gain research experience. You do not need an account or pay a fee to learn.