Skip to content

fix: defer the analytics flush schedule check to init - #22

Merged
tomasstark merged 1 commit into
betafrom
fix/defer-analytics-flush-schedule
Jul 16, 2026
Merged

fix: defer the analytics flush schedule check to init#22
tomasstark merged 1 commit into
betafrom
fix/defer-analytics-flush-schedule

Conversation

@tomasstark

Copy link
Copy Markdown
Contributor

This PR fixes the hourly analytics flush never being scheduled on sites where Action Scheduler is installed, which left buffered events stranded in the queue table and nothing ever reaching the relay or merchant dashboard.

Context

Action Scheduler's data store only initializes on init priority 1, but the plugin boots on plugins_loaded and Analytics_Dispatcher::register() called ensure_scheduled() synchronously right there. Called that early, as_has_scheduled_action() returns false and as_schedule_recurring_action() returns 0 without scheduling anything (both guarded by ActionScheduler::is_initialized(), with a _doing_it_wrong notice). Because Action Scheduler's functions exist at that point, action_scheduler_available() was true and the WP-Cron fallback was never reached either — the flush job ended up scheduled in neither backend.

Reproduced on a live install (1.3.0-beta.11, queue constant on, analytics opted in): events buffer into the queue table while neither Scheduled Actions nor wp cron event list contains supertab_connect_flush_analytics. wp-env never caught it because Action Scheduler isn't installed there, so the code fell back to wp_schedule_event(), which works fine at plugins_loaded.

Solution

register() now hooks ensure_scheduled() to init instead of calling it inline. The plugin boots at plugins_loaded, which always precedes init (including on cron requests), so the deferred check runs once Action Scheduler is ready; the WP-Cron fallback path is unaffected. ensure_scheduled() becomes public so WordPress can invoke it as a hook callback.

Verified end-to-end in wp-env with the action-scheduler plugin installed and SUPERTAB_CONNECT_USE_WP_QUEUE on: after the fix an admin request schedules the pending recurring action (no _doing_it_wrong notices), and firing the hook drains the buffer and POSTs the batch to /ingest/events. Events already buffered on affected installs will be delivered by the first flush after deploy; no migration needed.

Action Scheduler's data store only initializes on init priority 1, but
the dispatcher's ensure_scheduled() ran synchronously at plugins_loaded.
Called that early, as_has_scheduled_action() returns false and
as_schedule_recurring_action() returns 0 without scheduling anything —
and since Action Scheduler's functions exist, the WP-Cron fallback was
never reached either. On any site with Action Scheduler installed the
hourly flush was never scheduled at all, so buffered analytics events
accumulated in the queue table indefinitely and never reached the relay.

register() now hooks ensure_scheduled() to init instead of calling it
inline (the plugin boots at plugins_loaded, which always precedes init,
including on cron requests).
@tomasstark
tomasstark merged commit 8322a84 into beta Jul 16, 2026
5 checks passed
@tomasstark
tomasstark deleted the fix/defer-analytics-flush-schedule branch July 16, 2026 09:55
github-actions Bot pushed a commit that referenced this pull request Jul 16, 2026
# [1.3.0-beta.12](v1.3.0-beta.11...v1.3.0-beta.12) (2026-07-16)

### Bug Fixes

* defer the analytics flush schedule check to init ([#22](#22)) ([8322a84](8322a84))
@github-actions

Copy link
Copy Markdown

🎉 This PR is included in version 1.3.0-beta.12 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant