A learner starts a task on a phone, closes the tab, and returns later. The task should reappear with the correct evidence, draft, and status. This project treats that return journey as a requirement from the beginning.
Before you begin: Complete the MCP server and LangGraph lessons. Understand stable operation IDs and idempotency.
Choose a small end-to-end task
Build an assistant that reads a fictional workshop record, prepares a draft explanation, and waits for the learner to accept or revise it. Acceptance saves the draft inside the application. It does not send a message or create a booking.
Use the read-only MCP tool from the previous lessons as the source boundary. The workflow can call it through a compatible client adapter. Your model step receives only the retrieved evidence and the current question. Keep the lookup, draft generation, review, and save as separate operations so a failure can be located.
The important output is a recoverable task, not a long final response. Store a task ID, authenticated owner, status, source version, draft version, and operation IDs. Store secrets in the server's credential system, not in graph state shown to the model or browser.
Define the transitions
| Current state | Event | Result |
|---|---|---|
| Created | Source found | Evidence saved |
| Created | Source missing or unavailable | Explain the specific problem |
| Evidence saved | Draft produced | Awaiting review |
| Awaiting review | Learner edits | New draft version |
| Awaiting review | Learner accepts current version | Save once |
| Any active state | Learner cancels | Stop future work and record outcome |
An acceptance request must name the draft version. Otherwise a delayed phone request could accept text that changed after the learner read it. The server should compare versions atomically and reject stale acceptance with a clear recovery path.
What survives the loss of the process?
A variable in memory disappears when a process stops. A durable workflow needs enough stored state to recover the task’s identity, completed steps and remaining work. It also needs a way to distinguish a failed effect from an effect that succeeded just before the acknowledgement was lost.
Kill the process at a chosen boundary in the exercise and describe the exact recovery route. Test after a successful effect as well as before it. A workflow that only survives interruptions between harmless reads has not yet shown that it can recover a payment or reservation safely.
A reservation succeeds, then the worker stops before recording a response.
Restart and look up the operation by its stable identifier before attempting the effect again.
The workflow can reconcile the existing reservation rather than create a duplicate.
Implement one slice before the full integration
Start with a fixture source and deterministic draft. Persist a task, reload it in another process, and verify that only its owner can read it. Then replace the fixture adapter with MCP, and finally add the model call. This sequence makes a persistence bug visible without provider variability.
For the browser, render saved server status. “Generating” should come from an active task, “Awaiting review” from a saved draft, and “Saved” from a confirmed write. During a connection loss, show that the latest status is unknown and allow reconnection to the existing task ID. A second tap should not create an unrelated duplicate run.
This lesson specifies a project contract rather than claiming to supply a complete production app. Use your framework's authenticated routes and database transactions for the implementation. A dictionary in a Python process is a useful fixture, not durable storage.
Try to break recovery
Test disconnect after task creation, worker restart after evidence retrieval, source timeout, duplicate acceptance, stale acceptance after an edit, and a second user requesting the same task ID. Record expected and observed results separately.
The hardest case is a crash after the save succeeds but before the workflow records success. What should the resumed task do?
Inspect a recovery strategy
Query the saved draft using the stable operation ID. If it already exists with the expected owner and version, return that result and advance the task. Otherwise reconcile the uncertain outcome before attempting another write. The operation identity must survive retries; generating a new ID on every attempt defeats deduplication.
Show the finished evidence
Deliver a state-transition diagram or table, database shape, implementation, and failure-case results. Demonstrate returning to a saved task from a fresh session. If you used a simulated model, say so. If external MCP or provider calls were not exercised, list them as unverified integration steps.
Practice with feedback
Prove a workflow survives an interrupted session
Your workflow runs fine in development, where nothing ever crashes.
Build one slice, then try to break its recovery on purpose.
Make the decision before reading the feedback
Check your understanding
Now make something you can check
Define the slice, the checkpoints, and the interruption experiments with expected outcomes.
These notes stay on this page. Download them before leaving.
Check your reasoning against these points
- Checkpoints are at boundaries around external effects
- At least four kill points are covered
- Expected end state is identical across all of them
- Evidence is a recorded artefact, not an assertion
Compare with a worked answer
Compare the decisions and the evidence. Your wording can be different.
End-to-end slice: sign-up received -> validated -> charged -> place reserved -> confirmation emailed. Checkpoint points and what is written: after validate: state='validated', normalised fields before charge: state='charging', idempotency_key (written first, so a crash during the call is still recoverable by querying the provider) after charge: state='charged', charge_id after reserve: state='reserved', place_id after email: state='complete', notified_at
Interruption experiments | kill point | expected end state | duplicated effects allowed? | |---|---|---| | mid-validate | complete | none | | between validate and charge | complete | none | | during the charge call | complete, exactly one charge | no: key must dedupe | | between charge and reserve | complete, one charge, one place | none | | between reserve and email | complete | a duplicate email is tolerable, so the guard is best-effort |
How I observe the end state: query the signups row, the payment provider's charge list filtered by idempotency key, the class's booked count, and the mail provider's send log. Four independent sources, because the workflow's own view of itself is exactly what a recovery bug corrupts.
Completion evidence: a terminal recording of the five runs with the kill signal visible, plus the four queries after each, showing one charge, one place, and one email in every case. The during-the-charge run is the one worth keeping: my first attempt produced two charges because the key was written after the call rather than before it.
When you are signed in, opening the challenge carries your edited working notes into its draft in this browser. The challenge has its own completion record. Practising here does not award points or mark it complete.
Next, look more closely at MCP's protocol messages. That will help distinguish a transport problem from a workflow or application problem.
Sources
LangGraph durable execution explains replay boundaries. MCP specification defines the connection contract; it does not supply application-level task ownership.