Use lessons 01–04 or equivalent skills before this exercise. You can revisit them from the lesson list.
A computer and Python 3.10+. The supplied standard-library lab needs no API key, network or purchase.
Download the runnable offline builder lab →Start with the idea
Bound repeated work and describe what the teaching cache does not prove.
Recognize retries of the same intended operation. Stop when evidence is missing instead of guessing through more attempts. Explain storage and concurrency limits.
Idempotency: Repeated attempts at the same operation have one intended effect rather than duplicate effects.
See the example and check your understanding
A made-up teaching example
Operation K creates output A once. Repeating K returns its recorded result. A new request with no evidence stops rather than retrying until an answer sounds right.
Ask yourself
Does an in-memory teaching cache prove persistence across restarts?
Show the explanation
No. The exercise does not establish persistence, concurrency handling or live-provider behavior.
Start with these checks
- Count actual executions.
- Apply the retry limit.
- Record untested durability and concurrency.
Use the different practice case below and check every requirement in its full instructions.
Full learning objectives
- Keep evaluation cases separate from demonstrations.
- Handle duplicate operations deliberately.
- Avoid unbounded retries and side effects.
Captions appear here during playback.
Evaluate failures and bound repeated work
Bound repeated work and describe what the teaching cache does not prove.
Video playback is unavailable. Read the descriptive transcript below, go directly to practice, or open the video file.
Source-based teaching example · Fictional data · Reviewed 2026-10-03. Microsoft Mark · locally synthesized. On a small screen, use fullscreen for diagram details or read the transcript.
Read the descriptive transcript
0:00 · What you will learn
Bound repeated work and describe what the teaching cache does not prove.
What appears on screen
Bound repeated work and describe what the teaching cache does not prove.
0:07 · The idea
Recognize retries of the same intended operation. Stop when evidence is missing instead of guessing through more attempts. Explain storage and concurrency limits.
What appears on screen
Recognize retries of the same intended operation. Stop when evidence is missing instead of guessing through more attempts. Explain storage and concurrency limits.
0:20 · One useful term
Idempotency. Repeated attempts at the same operation have one intended effect rather than duplicate effects.
What appears on screen
Repeated attempts at the same operation have one intended effect rather than duplicate effects.
0:30 · A worked example
Operation K creates output A once. Repeating K returns its recorded result. A new request with no evidence stops rather than retrying until an answer sounds right.
What appears on screen
Operation K creates output A once. Repeating K returns its recorded result. A new request with no evidence stops rather than retrying until an answer sounds right.
0:44 · Your turn to think
Does an in-memory teaching cache prove persistence across restarts? Pause and decide before continuing.
What appears on screen
Does an in-memory teaching cache prove persistence across restarts? Pause the video if you need more time.
1:02 · Why this answer works
No. The exercise does not establish persistence, concurrency handling or live-provider behavior.
What appears on screen
No. The exercise does not establish persistence, concurrency handling or live-provider behavior.
1:12 · Check 1
Count actual executions.
What appears on screen
Count actual executions.
1:17 · Check 2
Apply the retry limit.
What appears on screen
Apply the retry limit.
1:21 · Check 3
Record untested durability and concurrency.
What appears on screen
Record untested durability and concurrency.
1:27 · Now try a different case
Open the lesson and try its different practice case. Use every check in the full task. Watching alone does not mark the lesson complete.
What appears on screen
Open the lesson Try the new case Check and revise The full task and its requirements are in the linked lesson.
Watching explains the example. Complete the lesson practice to check what you can do. Explore all visual lessons →
The method
Create cases for the normal path, missing evidence, denied access, malformed input, refusal and partial failure. Define expected behavior before inspecting results. Keep separate cases for development and independent evaluation; repeatedly tuning to the same small fixture can hide poor generalization. Report each consequential failure instead of only an aggregate score.
Retries need a limit and a reason. Repeat read operations may be harmless; repeated writes can duplicate work. Use an application-level operation key and an atomic durable design when production requires it. This lab uses an in-memory map to illustrate idempotent result reuse in one process; it does not solve concurrent or cross-process delivery.
Choose your model, harness and offline route
Text-only assistant
Use supplied text. Ask for a plan or draft; do not claim browsing, code execution or file access that was unavailable.
Tool-enabled application or harness
Record which tools actually run, allowed files and actions, approval boundaries and observable results. Tools are optional unless the task needs them.
Local or cloud deployment
Inspect inference, retrieval, connectors, logs and storage separately. Use only authorized environments for real data; training fixtures are fictional.
Higher-capability or frontier model
Evaluate the exact task and configuration. Capability does not supply missing evidence or grant permission. No provider ranking or guarantee is implied.
Offline alternative
Use the supplied inputs and inspect the worked example manually. Builder exercises use local deterministic Python. No paid account or live model call is required.
Record the exact product/model label when available, tools actually used, inputs, permitted actions, observed output and checks. Live accounts or APIs may have external costs; they are optional and are not used by this page.
Read the general workflow guide →Worked example
Supplied input
Fictional requests: operation K runs once and produces artifact A. A retry reuses K. A new request L has no evidence. Retry limit is two attempts.
A checked result
K returns the same stored result without another side effect. L stops with a missing-evidence status rather than retrying until a plausible answer appears.
Why this works
Repeatability and failure honesty are design requirements. An in-memory teaching cache has explicit durability limits.
Try a different case
Independent lab stage: implement once in starter.py. For repeated operation IDs, reuse the first result without calling the supplied operation again. Add one fresh evaluation case beyond the supplied tests.
Download this task and checklist →Interactive practice / Fictional fixture
Compare retry strategies
Run a simulated K → K → L sequence. The trace counts a fictional operation; nothing is sent, written remotely or purchased.
Everything runs in this browser. No AI model is called and no work is uploaded. Bounded checks cover specific facts and rules. Your writing is not graded: you review it yourself. Practice never marks a lesson complete automatically.
This is one in-memory process. It is not a durable or concurrent production guarantee.
Try the task, run the checks, then revise. Checks are teaching feedback, not an instructor grade.
Observed browser simulation
This trace comes from the bounded local checker. It is not a Python run, model result or production tool execution.
Keep or restore your work
Drafts are not saved automatically. Save only fictional practice data. A browser draft may be lost if storage is cleared; download a copy to keep it.
Your steps
- Count operation calls for repeated and new IDs.
- Run supplied tests and your extra case.
- Write a release gate distinguishing fixture success from real-world coverage.
Check your work
- Repeated ID executes once in the process.
- New ID executes separately.
- Document lack of persistence, concurrency handling and live-provider evaluation.
After your attempt: review notes and a common mistake
Calling the operation then discarding its second result still repeats the side effect. Check the cache before execution. Real production designs need stronger persistence and concurrency guarantees.
Different wording or a different justified decision can pass. Check your work against every requirement; these notes are not an automated grade.
The lab’s reference.py is a worked solution. Run python check.py --reference only to inspect feedback after your attempt; passing the reference does not complete your work.
Explain your approach
What failure remains outside this lab’s guarantee?
Keep your artifact, one correction or decision, its evidence and one remaining limitation. Nothing on this page sends or uploads your work.
Check your understanding
Choose an answer to see feedback. This is a knowledge check, not instructor assessment.
Review your independent practice
Complete the supplied task before recording progress. Use the acceptance criteria and reveal the review notes after your attempt. Keep your artifact yourself; nothing is uploaded.
Not yet self-reviewed. Completion stays in this browser and does not issue a badge.
Optional deeper study
Explore the related general-course lesson → This opens the existing canonical lesson; it is optional depth, not another copy of this focused task.
Primary references
Revision 2026-10-03. Fictional examples, not observed provider results. Knowledge checks and completion records are self-study aids.