iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To stop a scheduled agent from creating the same draft again, give each intended post a stable identity, store that identity durably, and make draft creation conditional or idempotent. A scheduler may avoid registering the same job twice, but that does not guarantee the job’s separate write to a CMS happens only once. Retries, restarts, timeouts, and concurrent workers all need protection at the draft-creation boundary.
Why a scheduled agent can create duplicate drafts
A retry can repeat a side effect. If a create request reaches the CMS but the response times out, the agent may not know whether the draft was saved. Retrying with a new request can then create a second draft. AWS’s idempotency guidance identifies retries as a common source of duplicate side effects when operations are not idempotent.
There are two distinct operations to protect:
- Schedule registration: whether the scheduler has already registered the intended callback.
- Draft creation: whether the callback has already created the intended post in the CMS.
Deduplicating the first does not automatically deduplicate the second. The agent’s write needs its own durable check.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Give each intended post a stable identity
Compute a deterministic key for the post slot, such as a logical_post_id derived from a durable campaign or schedule identity and the intended slot or event identity. Use the same key every time the same logical operation is retried. Do not generate a fresh random UUID or use the current timestamp on each attempt: those values change across retries and defeat deduplication.
#1 Best Overall
The exact inputs depend on what your application considers “the same post.” For a recurring campaign, the identity might combine the campaign with a particular occurrence. For an event-triggered post, it might combine the workflow with the event identifier. Ensure that distinct intended posts produce distinct keys, while retries for one intended post produce the same key.
Make the create path durable and concurrency-safe
- Claim the key before creating the draft. Insert or claim the logical key in durable storage, protected by a unique constraint or conditional write. This makes the database—not a timing-sensitive “check then create” sequence—the arbiter when two workers run at once.
- Look up existing state. If the key already exists, inspect its status and linked draft. If the operation succeeded, return the stored result instead of creating another draft. If it is incomplete, resume or reconcile it rather than starting blindly.
- Pass the same key downstream. If the CMS create API accepts an idempotency key, send the stable key with the request. In a multi-step workflow, propagate the parent key or a deterministic derivative to downstream operations.
- Retain idempotency records for the retry window. Expiring records too early can allow a delayed retry to create a duplicate. AWS recommends tying TTL-based expiration to the expected retry window.
A local record is still valuable when the CMS has no idempotency-key feature. It provides a durable place to record the attempt and a basis for checking whether a timed-out request created a post. Do not treat a timeout as proof that the write failed.
Track progress so crashes and timeouts can be recovered
A simple lifecycle might be planned → creating → draft_saved → scheduled/published, with explicit failure or unknown-outcome states as needed. Store the logical key, current status, and any external post identifier together so a retry can inspect the previous attempt.
The creating state needs a recovery rule. A worker can crash after claiming the key but before recording the CMS result. Use a lease, reconciliation step, or another defined recovery mechanism so an abandoned attempt does not block the post forever. If the outcome is unknown, query by the logical key or external post identifier before sending another create request. This state-machine approach is a design pattern; exact guarantees depend on the database and CMS API you use.
Keep scheduler deduplication separate from draft deduplication
Cloudflare Agents’ scheduling documentation describes different deduplication behavior by schedule method:
| Schedule method | Documented deduplication behavior | What it does not guarantee |
|---|---|---|
| Cron | Idempotent by default for matching callback, cron expression, and payload. | That an external CMS write inside the callback is idempotent. |
| Delayed and date-based | Non-idempotent by default; deduplication can be opted into using callback and payload. | That the draft API has accepted or saved only one post. |
scheduleEvery() |
Idempotent on callback, interval, and payload; the docs say it can safely be called in onStart() under those semantics. |
Protection for side effects performed by each scheduled callback. |
The same documentation distinguishes these Agent scheduling methods from the Scheduler primitive, which it describes as experimental. Confirm the installed package version before relying on API details.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Drafts are not published posts
Payload CMS documents drafts as versions stored separately from the published document: a normal read returns the published document, while a draft read can fetch the latest version. Its scheduled publish and unpublish features create background jobs, so the application needs a mechanism to process those jobs. Draft visibility also depends on access control; using the draft read argument alone does not prevent unauthenticated users from receiving draft documents. See the Payload drafts documentation.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteThese lifecycle features do not replace an application-level idempotency key. Treat creation, scheduling, and eventual publishing as distinct operations with their own recorded state and permissions.
Best Value
What to verify in your stack
- Does the CMS create endpoint accept an idempotency key, and how long does it retain keys?
- Can your database enforce uniqueness or conditional writes for the logical post key?
- Can a retry find a prior draft by key or external identifier after a timeout?
- Does the idempotency record outlive the longest retry or delayed-job window?
- Are drafts kept separate from published content, and are draft reads restricted by access control?
- Does the installed scheduler version match the documented schedule semantics you intend to rely on?
The sources establish patterns and behaviors for AWS guidance, Cloudflare Agents, and Payload CMS, but they do not establish one universal API contract or transaction guarantee. Check the specific versions and services in your application before implementing the pattern.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
