WordPress Action Scheduler: poll a Sume run as a queued action

Use Action Scheduler for the Sume part of a WordPress site by queuing two short actions: one that submits the run and one that checks it later. Each action should finish in seconds, because the library claims batches of 25 actions, stops a batch at 30 seconds or 90 percent of memory, and marks an action that runs over 5 minutes as failed. A render that takes many minutes does not fit inside one action.

The Action Scheduler facts are from the project's own page, Action Scheduler, read 2026-10-10. The Sume facts are from Create a run and Runs and results.

What does the queue guarantee?

The project page says a queue runner starts every minute through WP-Cron, can be triggered by an async loopback request, and can also be run from WP-CLI. It claims a batch of 25 actions at a time, and stops when it uses 90 percent of the available memory or runs for 30 seconds. Actions that run for more than 5 minutes are marked as failed. These numbers decide the shape of your Sume code.

How do I split the work?

Action one reads the post, builds the input and sends POST /v1/formats/{handle}/{slug}/runs with an Idempotency-Key made from the post id and a content version. It stores data.id as post meta and queues action two for a later time. Action two calls status_url; if the status is not terminal it queues itself again, and if it is terminal it fetches the result and attaches the media.

This is also where a retry becomes safe. If the runner fails action one after Sume accepted the request, the next attempt sends the same key and gets 200 with idempotency_hit: true and the original run, not a second paid render.

Whichever you choose, log the run id on the post so a person can find the receipt later. The id is the handle for everything else: status, result, cancel and redeliver all take it.

Why not use the Sume webhook instead?

A webhook is better when your site is reachable. Give the run a communication.webhook_url that points at a REST route, and Sume sends one format.run.terminal event per run. The Run webhooks page says delivery retries for 10 attempts with a 10 second timeout, and that a redirect counts as a failed attempt, so a site that redirects HTTP to HTTPS or adds a trailing slash can lose deliveries. Verify the signature before you do anything else.

Keep polling as the fallback. Many hosting setups block loopback requests or run WP-Cron rarely, so a site may see neither the webhook nor a timely poll. A slow poll action every few minutes costs one request and is cheap insurance.

What should the poll action check?

Read status first and expires_at second. The runs page says a non-terminal receipt carries expires_at, the 90 minute deadline after which Sume force-finalizes the run as failed. If the current time is past it and your poll still sees no result, stop queuing and flag the post for a person.

Media URLs from a finished run are durable media.sume.com HTTPS URLs that do not expire, so the action can store the URL or sideload the file into the media library; the choice is yours, and neither depends on a clock.