Action delivery and retries

Form submission, paid fulfillment, manual replay, the action tester, and queue workers use the same action runner. Missing handlers and false/WP_Error failures never count as success. A legacy callback that returns no outcome is marked unverified; observers that return nothing do not override a reported action result.

HTTP integrations require a successful response status. Authentication and validation failures are terminal until configuration is corrected. Rate limits, selected transient HTTP failures and transport errors are retryable. Messages are redacted before the general action log is written. Provider acceptance does not prove final email/message delivery.

Background execution

Eligible action cards have a Run in the background checkbox. It requires a saved submission; when storage is disabled, execution stays synchronous and no hidden submission snapshot is persisted. Checkout handoffs, browser redirects and account/content creation remain synchronous. Eligible transient failures from synchronous actions can also enter the queue.

The queue retries transient failures with exponential backoff and respects Retry-After. Permanent or unreported failures do not retry automatically. WordPress cron must be running. Failed queue rows can be retried through the existing workflow endpoint after configuration is corrected. Manual retry resolves the current configuration of the same action; it refuses removed or ambiguous actions. Configuration changes create a fresh execution key, while unchanged configurations retain their completed-step checkpoints.

Duplicate prevention

Every saved submission/action/configuration has a stable execution key. Unstored submissions use a per-submission ephemeral ID. Execution claims have an expiring lease, and an expired worker cannot overwrite a newer worker’s completion. ActiveCampaign and Kit checkpoint completed steps and resume only unfinished operations on retry.

Retries provide at-least-once delivery when the remote provider has no idempotency mechanism. A timeout after a remote side effect can still require provider-side deduplication. Native claim recovery prevents permanently stuck runs; it cannot make an external API transaction atomic with WordPress.

Settings and mappings

Unavailable integrations remain visible as disabled cards. Their settings stay on the server and survive saving the Actions tab; removing the card explicitly removes the action. A concurrent settings change requires reloading rather than overwriting a different configuration.

Field selectors use the form’s actual names and validate mappings before saving. Exact case wins; only an unambiguous case alias is resolved for legacy defaults. Native adapter checkboxes submit explicit zero values, so default-on options can stay off.