Course lesson 38 · Managing Workflows with Durable Objects
Full Link Click Integration with Alarms
The persistent counter becomes a working evaluation scheduler integrated with the link-click consumer. Each object stores click context, schedules an alarm only when no alarm is pending, and starts the destination workflow when that alarm fires. The demonstration uses ten seconds to verify the full pipeline and then changes the interval to twenty-four hours so repeated clicks share one scheduled evaluation.
Primary source: course video 38 · Supplied English subtitles · 00:23:25.
Understand the idea
- The implemented object identity combines link ID and destination URL, so grouping is more specific than URL alone.
- collect-link-click updates both in-memory and persistent context for the future alarm.
- Checking for an existing alarm prevents each additional click from scheduling another evaluation or pushing back the existing alarm.
- The alarm validates that context exists and creates a workflow with typed link, destination, and account parameters.
- A custom environment interface refines the workflow binding’s payload type without editing the generated configuration file.
What the course does
- Remove the teaching counter and its temporary route, then introduce persisted click context.
- Implement collection to save that context and create an alarm only if none exists.
- Implement the alarm callback to require click data and create the workflow instance.
- Refine the binding type so workflow creation checks its input parameters.
- Extend the queue handler to resolve the object from link ID plus destination URL and pass the click context to it.
- Deploy and follow one click through redirect, queue, D1, alarm, workflow, and stored screenshot.
- Change the delay from the ten-second demonstration to twenty-four hours and extract scheduling calls into a helper.
Watch for
- This is click-triggered scheduling, not an autonomous daily cron: a later click is needed to schedule another alarm after the pending one fires.
- Later playback shows the earlier four-step workflow; retain lesson 34’s size-limit correction in your final implementation.
- Added advice: retries and partial failures can repeat persistence or workflow creation, so scheduling alone does not establish exactly-once processing.
Follow the final workflow correction in lesson 34 when combining these steps.
Recall before revealing
If a destination receives no further clicks after an evaluation, will this scheduler automatically evaluate it again tomorrow?
Reveal the explanation
No. The implementation schedules from incoming clicks when no alarm is pending; it does not show the alarm scheduling its own next run.
Try it
Trace clicks at minute zero, minute five, and after the first alarm has fired. State how many pending alarms and workflow launches exist at each point.
Check your result
Your trace shows one shared pending alarm before the first firing and a new delayed run only after another click arrives.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Rewatch only what you need
Open this lesson in your original course library and seek to the times below. Videos are not hosted on this site.
- 00:02:02 — Persistent click context replaces the counter
- 00:04:52 — Schedule only when no alarm exists
- 00:08:46 — Refining workflow input types
- 00:13:40 — Identity combines link and destination
- 00:19:49 — Changing the delay to twenty-four hours
Companion primary documentation: What are Durable Objects?. For recorded API names, commands, limits, and prices, check the version you use.