[pcfreak30]

Summary

Action Scheduler due jobs are driven each supervised WP_CRON_INTERVAL via its queue hook. The cron worker now fires Action Scheduler's own action_scheduler_run_queue hook on every tick, passing the same canonical WP Cron execution context AS's built-in WP-Cron queue event passes (the hook's second argument is AS's execution-context/log label, not an identifier), so due actions run on this short cadence instead of waiting for AS's 1-minute WP-Cron queue event — and AS log entries match its built-in runner.

• Preserves core WP-Cron: wp cron event run --due-now is unchanged — cron semantics stay WordPress-native; no DIY scheduler, no duplicate schedule.
• Class guard: class_exists("ActionScheduler_QueueRunner") makes the hook a no-op on sites without Action Scheduler (Cast vendors it).
• Canonical context: the worker fires the hook with the native WP Cron context label, so AS batch/log semantics agree with the built-in WP-Cron runner.
• Warning / retry: a failing AS queue run is warned to stderr and retried next tick — never fatal to supervision.

Verification evidence

• make verify-wordpress: full local build + verification matrix passes, including the new check that a due AS action runs within the 5s cron cadence while the AS WP-Cron queue event is pushed 90s out, and a check that captures the action_scheduler_run_queue context argument (via a temporary mu-plugin) and asserts it is the canonical WP Cron.
• make lint: shellcheck clean on both touched scripts.
• Supervisor: the AS run lives in the same supervised loop; a worker crash takes the container down (fail-fast), transient failures retry next tick.
• Mutation: pushing the AS WP-Cron action_scheduler_run_queue event 90s out (via wp eval, retrying to defeat a lost update) proves the legacy 1-minute path cannot be what runs the action within the 40s deadline — direct queue driving is confirmed.

No changes to the Cast repo.

---

Summary

This PR makes the WordPress pinner cron worker drive due Action Scheduler actions on the same short cadence already used for WordPress cron events.

Previously, the worker only ran WordPress cron events that were due. Action Scheduler due actions still depended on Action Scheduler’s own 1-minute WordPress cron queue event, so they could wait up to a minute before running. The worker now also triggers Action Scheduler’s queue hook on every tick, allowing due Action Scheduler actions to execute on the worker’s own cadence without adding a separate, non-WordPress scheduler.

Changes

• images/wordpress/pinner-wp-cron.sh

  • Updates the worker’s purpose to explain that it now drives both WordPress cron events and the Action Scheduler queue.
  • After running due WordPress cron events, the worker now executes a guarded WordPress evaluation that fires the action_scheduler_run_queue hook when Action Scheduler is present.
  • If the Action Scheduler queue run fails, the worker logs a warning and continues, retrying on the next tick rather than terminating the supervised process.
  • The class_exists guard keeps this a no-op on sites where Action Scheduler is not available.

• scripts/verify-wordpress.sh

  • Adds verification that the worker runs due Action Scheduler actions on its own cron cadence.
  • Pushes Action Scheduler’s native 1-minute WordPress cron queue event into the future to rule out the default AS cron path as the source of execution.
  • Uses a temporary mu-plugin to observe a test Action Scheduler action.
  • Confirms the test action runs within a 40-second window, proving the worker drives the Action Scheduler queue directly on the shorter cron cadence.
  • Cleans up the temporary mu-plugin after the check.

Functional impact

• Due Action Scheduler actions no longer have to wait for Action Scheduler’s default 1-minute WordPress cron queue event.
• Action Scheduler work becomes more responsive inside the WordPress container by running on the existing worker tick interval.
• The change keeps scheduling within WordPress-native mechanisms: WordPress cron events and Action Scheduler’s own queue hook.
• The verification suite now explicitly validates the faster Action Scheduler execution path.

Review note

A high-severity review finding notes that firing action_scheduler_run_queue on every tick doubles the frequency relative to Action Scheduler’s 60-second lock-expiry window. If a queue run is slow, this could allow two concurrent queue runs and potentially execute due actions twice.

[kody-ai]

Duplicate queue execution in images/wordpress/pinner-wp-cron.sh: unconditional action_scheduler_run_queue on every WP_CRON_INTERVAL tick (30s, line 25) doubles the frequency of Action Scheduler 3.x's 60s action_scheduler_lock_timeout probes around ActionScheduler_QueueRunner::run(), in addition to AS's own 1-minute WP-Cron queue event, allowing slow non-idempotent batches to re-enter while a queue run is in flight after lock expiry. Raise the AS lock timeout above the longest expected batch (e.g., add_filter('action_scheduler_lock_timeout', fn() => 300)) and confirm that filter name against the vendored AS version in the Cast plugin.

if ! "$WP" --path="$DOCROOT" eval '
    if ( class_exists( "ActionScheduler_QueueRunner" ) ) {
        // keep AS process-lock timeout above the longest expected batch
        // so a slow run cannot be re-entered by the next tick
        add_filter( "action_scheduler_lock_timeout", function () { return 300; } );
        do_action( "action_scheduler_run_queue", "Pinner WP Cron" );
    }
' >/dev/null 2>&1; then

Prompt for LLM

File images/wordpress/pinner-wp-cron.sh:

Line 59 to 63:

Duplicate queue execution in images/wordpress/pinner-wp-cron.sh: unconditional action_scheduler_run_queue on every WP_CRON_INTERVAL tick (30s, line 25) doubles the frequency of Action Scheduler 3.x's 60s action_scheduler_lock_timeout probes around ActionScheduler_QueueRunner::run(), in addition to AS's own 1-minute WP-Cron queue event, allowing slow non-idempotent batches to re-enter while a queue run is in flight after lock expiry. Raise the AS lock timeout above the longest expected batch (e.g., add_filter('action_scheduler_lock_timeout', fn() => 300)) and confirm that filter name against the vendored AS version in the Cast plugin.

Suggested Code:

    if ! "$WP" --path="$DOCROOT" eval '
        if ( class_exists( "ActionScheduler_QueueRunner" ) ) {
            // keep AS process-lock timeout above the longest expected batch
            // so a slow run cannot be re-entered by the next tick
            add_filter( "action_scheduler_lock_timeout", function () { return 300; } );
            do_action( "action_scheduler_run_queue", "Pinner WP Cron" );
        }
    ' >/dev/null 2>&1; then

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

​

​

[kody-ai]

Code Review Completed! 🔥

The code review was successfully completed based on your current configurations.

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the @kody start-review command at the root of your PR.

• Validate Business Logic: Ask Kody to validate your code against business rules by adding a comment with the @kody -v business-logic command.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

​

[kody-ai]

Cache assertion failure in scripts/verify-wordpress.sh: the new compare-and-delete verification block asserts cache:kept via wp_cache_get($key, 'action_scheduler_locks'), but AS 4.2's ActionScheduler_OptionLock::set() is pure $wpdb with no wp_cache_set/wp_cache_delete on that group, so wp_cache_get returns false, printf emits cache:lost, the [ "$as_cas_cache" = "cache:kept" ] check dies on every conclusive attempt, and set -euo pipefail makes verify-wordpress.sh deterministically fail. Remove the wp_cache_get line, cache:kept/cache:lost ternary, as_cas_cache read, and cache:kept die; keep only the as_cas_b/as_cas_db parse, db:kept assertion, and DB-only pass message.

Prompt for LLM

File scripts/verify-wordpress.sh:

Line 344 to 358:

Cache assertion failure in scripts/verify-wordpress.sh: the new compare-and-delete verification block asserts cache:kept via wp_cache_get($key, 'action_scheduler_locks'), but AS 4.2's ActionScheduler_OptionLock::set() is pure $wpdb with no wp_cache_set/wp_cache_delete on that group, so wp_cache_get returns false, printf emits cache:lost, the [ "$as_cas_cache" = "cache:kept" ] check dies on every conclusive attempt, and set -euo pipefail makes verify-wordpress.sh deterministically fail. Remove the wp_cache_get line, cache:kept/cache:lost ternary, as_cas_cache read, and cache:kept die; keep only the as_cas_b/as_cas_db parse, db:kept assertion, and DB-only pass message.

_{Talk to Kody by mentioning @kody}

_{Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.}

​

​