# Production guide — Follow a scheduled action to its result

Companion to [the full course](../appengine-run-reliable-background-jobs.md). This package supplies real Studio stills, actual sanitized API transcripts and queue evidence. No finished video is included.

## Opening and structure

Open on the three facts in `04-success-readback.png`: schedule done, note ready, one successful run. Narration: “A saved schedule, a queued job and a changed business record are different things. We will check all three.” Explain that this rehearsal uses a harmless internal note so it can demonstrate failures without sending messages or making payments.

| Scene | Material | Essential point |
| --- | --- | --- |
| Orient | `../../application-fixes/assets/jobs-local/07-overview-fixed.png` | Overview, Upcoming, Runs and Logs; database versus queue |
| Create target | `target-create.json` | Note begins waiting; retain its ID |
| Schedule | `schedule-request.json`, `queued-before.json` | Future ISO time, target datatype and ID, update-status action |
| Observe due time | `04-success-readback.png` | Target becomes ready and one activity says success |
| Read history | `../../application-fixes/assets/jobs-local/09-runs-fixed.png`, `10-run-details.png` | API success appears as completed; open the actual activity |
| Fail deliberately | `failure-request.json`, `failed-queue-job.json` | Missing datatype fails three attempts |
| Repair | `05-failure-recovery.png`, `recovery-update.json` | Correct the same record, choose a future time, inspect new run |
| Pause practice | `08-controls-before.json`, `08-controls-after.json` in jobs-local | Stop persists, queue entry removed, target unchanged after due |
| Delete practice | `12-delete-final-before.json`, `12-delete-final-after.json` in jobs-local | Record and queued job removed before due; target unchanged afterward |
| Apply the lesson | Simple record → queue → worker → target diagram | External delivery needs additional evidence |

Assets are in [the jobs directory](../assets/appengine-jobs). API-output images are text transcripts of actual results, clearly distinct from Studio UI.

## Recording the timed action

Use a fresh training record for a new continuous recording, or explain that you are reviewing the supplied recorded results. Calculate a future time on camera. Never reuse the historical due time as if it were still ahead. Show the target ID entering the schedule, the schedule ID entering the queue lookup, and the job ID used for correlation.

Hold the delayed state long enough to read scheduledFor and attempts. Cut the waiting period with an explicit time transition; do not imply the job ran immediately. After the due time, read schedule, target and history separately. The successful run status is success; the schedule state is done. Keep those labels exact.

The first schedule had only a start time and created one job. Do not animate an end job that was not configured. Explain that a later end date is a separate optional action. The job may disappear after completion because removeOnComplete is true; the saved activity and target remain the evidence.

## Failure and recovery sequence

Show the malformed target with its datatype missing. The API accepted the record, but the worker failed at execution. Display attemptsMade 3 and the exact datatype error from the captured job. Then show that the database record still said active and the run-history endpoint was empty. This is the teaching moment: each surface observes a different stage.

Use only the matching training job from queue details. The global endpoint can include other organizations' metadata; never scroll through unrelated jobs in footage. The supplied evidence has already restricted the result to our fixture.

Read the latest schedule before editing. Add the target datatype, retain the other fields, calculate a new future time and submit the full current record. The update returned version 1. Show its successful activity after the new due time. If filming a fresh run, read the target immediately after recovery before another experiment overwrites it. The fresh `06-repair-result.json` captures the target as reviewed; later safety tests use separate targets.

## Pause and deletion must stay honest

Use the 24 September acceptance evidence in `application-fixes/assets/jobs-local`. The older PAUSED-executed and orphaned-job captures document pre-fix failures and must not illustrate current behavior. Show Pause saving stop, the queue job disappearing, and the target still waiting after due. Then show a separate schedule being deleted, its record returning404, queue entry absent before due and its own target unchanged afterward. Keep the wait explicit. Do not suggest these operations reverse an already-running external action.

Do not demonstrate shared queue pause, cluster sync removal, card charges or real reminder sends as visual filler. These are different operations with broader consequences than the training fixture.

## Visual treatment and final checks

Use four consistent labels: Record, Queue, Worker, Result. Animate the conceptual arrow only when the corresponding observed stage appears. Keep identifiers abbreviated consistently in overlays, while the companion Markdown retains complete request structures. Narrate text as well as color; success, delayed and failure must not be distinguished by color alone.

Before publishing, recheck schedule pause enforcement, cancellation cleanup, Runs UI, status counters and the stats endpoint on the release being filmed. Replace a limitation only after repeating its full action and readback. Confirm no secrets or unrelated queue data appear. End by linking the platform-operations course for diagnosis and the business workflow course for deciding what should be automated.