fix: defer the analytics flush schedule check to init - #22
Merged
Conversation
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).
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))
|
🎉 This PR is included in version 1.3.0-beta.12 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
initpriority 1, but the plugin boots onplugins_loadedandAnalytics_Dispatcher::register()calledensure_scheduled()synchronously right there. Called that early,as_has_scheduled_action()returnsfalseandas_schedule_recurring_action()returns0without scheduling anything (both guarded byActionScheduler::is_initialized(), with a_doing_it_wrongnotice). 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 listcontainssupertab_connect_flush_analytics. wp-env never caught it because Action Scheduler isn't installed there, so the code fell back towp_schedule_event(), which works fine atplugins_loaded.Solution
register()now hooksensure_scheduled()toinitinstead of calling it inline. The plugin boots atplugins_loaded, which always precedesinit(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-schedulerplugin installed andSUPERTAB_CONNECT_USE_WP_QUEUEon: after the fix an admin request schedules the pending recurring action (no_doing_it_wrongnotices), 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.