`visualizer_schedule_refresh_db` remains missing after Visualizer reactivation

Summary

Visualizer's recurring database-refresh action can remain absent after the plugin is deactivated and reactivated. Reactivation is expected to register visualizer_schedule_refresh_db, as documented, but the reported installation still has no scheduled action afterward. Database-backed charts therefore lack their recurring refresh trigger and may remain stale until manually refreshed.

Customer context

• Product / area: Visualizer scheduled database refresh
• Version: Visualizer 4.0.8; Visualizer Pro 2.0.2
• Environment: WordPress 7.1.1; PHP 8.3.24; single-site status not explicitly confirmed
• Integration / third party: Bundled Action Scheduler 3.9.3
• Reported error / symptom: visualizer_schedule_refresh_db is missing after a deactivate/reactivate cycle; no scheduling error appears in the available Visualizer log
• Impact: Scheduled database-chart refreshes have no recurring trigger
• Integrity: Diagnostics reported that the installed free and Pro plugin files match their official releases

Reproduction notes

1. Use Visualizer 4.0.8 with Visualizer Pro 2.0.2 and a database chart that depends on scheduled refreshes.
2. Observe that visualizer_schedule_refresh_db is absent under Tools > Scheduled Actions.
3. Deactivate and reactivate Visualizer once, following the product documentation.
4. Return to Tools > Scheduled Actions and search for the hook.
5. Reported result: the action remains missing while other WordPress and plugin scheduled tasks work.

This is a customer-verified runtime reproduction. Repository inspection confirms a lifecycle path that can leave both schedulers empty, but the exact Action Scheduler state that triggered this installation's failure was not captured.

Diagnosis

Conclusion

The released lifecycle code has a confirmed gap that can produce and preserve the reported state. On the Action Scheduler path, Visualizer checks only whether a next action is reported, does not inspect the result of recurring-action creation, clears the WP-Cron fallback, and returns. If registration yields no usable action, both scheduling systems can be empty. Ordinary requests do not recreate the action, and the upgrade path runs only when a legacy WP-Cron event exists. The customer's intact 4.0.8 installation remained without the action after the documented reactivation procedure.

Where this likely occurs

• classes/Visualizer/Module/Setup.php — Visualizer_Module_Setup::__construct() lines 42-58 registers activation/deactivation and the refresh callback but no recurring-action recovery hook.
• classes/Visualizer/Module/Setup.php — Visualizer_Module_Setup::activate_on_site() lines 211-218 invokes recurring-action registration during activation.
• classes/Visualizer/Module/Setup.php — Visualizer_Module_Setup::schedule_refresh_db_action() lines 486-504 calls as_next_scheduled_action(), conditionally calls as_schedule_recurring_action(), then clears the WP-Cron event without checking whether a usable Action Scheduler record was created.
• classes/Visualizer/Module/Setup.php — Visualizer_Module_Setup::unschedule_refresh_db_action() lines 509-516 removes both Action Scheduler and WP-Cron registrations during deactivation.
• classes/Visualizer/Module/Upgrade.php — Visualizer_Module_Upgrade::upgrade() lines 18-40 invokes migration only when wp_next_scheduled() finds a legacy event, leaving the both-missing state untouched.
• classes/Visualizer/Module/Upgrade.php — Visualizer_Module_Upgrade::migrate_action_scheduler() lines 86-103 similarly clears WP-Cron after attempting Action Scheduler registration without validating the resulting action.
• index.php — visualizer_launch() lines 148-157 loads the bundled Action Scheduler entry point when the release artifact contains it.
• Commit bc14d4b8 introduced the Action Scheduler migration after v3.11.15; the affected behavior is present in released tag v4.0.8. This establishes the code history but does not by itself prove the customer's exact failure is a regression.

Engineering notes

• The free plugin owns visualizer_schedule_refresh_db; the Pro add-on manages a separate visualizer_schedule_import action and does not override this lifecycle.
• Action Scheduler 3.9.3 exposes a recurring-action assurance mechanism, but no corresponding Visualizer registration was found in v4.0.8.
• Action Scheduler's documented API indicates scheduling calls can return a zero action ID when creation fails. The release path does not distinguish that outcome before removing the fallback.
• An exact storage-level failure or stale Action Scheduler status has not been captured from the affected installation, so the immediate runtime trigger remains unknown.
• Open issue #1361 was read and rejected as a duplicate: it concerns a wpdb::db_server_info() fatal on WordPress 5.3, not a missing action on WordPress 7.1.1.
• Merged commit 1880fdd8 is not in a release tag and adds recovery only when Action Scheduler is unavailable; its inspected branch returns early when Action Scheduler is usable, so it does not establish that this WordPress 7.1.1 report is already fixed.

Test coverage status

tests/test-import.php checks that the custom ten-minute interval exists, and tests/test-schedule.php covers scheduled import behavior. No relevant coverage was found during inspection for activation/deactivation registration, failed Action Scheduler creation, migration with both schedulers empty, or recovery of a missing visualizer_schedule_refresh_db action. The inspected Visualizer Pro scheduler tests concern the separate import action.

What to verify or explore next

• Reproduce with released Visualizer 4.0.8 and Action Scheduler 3.9.3 by removing all visualizer_schedule_refresh_db records, then running the documented deactivate/reactivate sequence.
• Inspect all Action Scheduler statuses and logs for the Visualizer group immediately before and after reactivation.
• Capture the return value and resulting stored record from the recurring-action registration call during activation.
• Run activation, deactivation, migration, and both-missing recovery scenarios on single-site and multisite installations.
• Confirm behavior when another active plugin supplies a different Action Scheduler version.

Unknowns / follow-up

• The affected site's full Action Scheduler status inventory and system information were not available.
• It is unknown whether a stale, failed, canceled, or in-progress record influenced the next-action lookup.
• No local runtime reproduction was performed because the checkout lacks the built vendor/ directory and a matching WordPress test environment.

Confidence

Confidence: 88/100

The affected released code can leave the recurring refresh action absent: it does not verify Action Scheduler registration succeeded, clears the WP-Cron fallback on the Action Scheduler path, and has no recovery check when both records are missing. The customer reproduced the missing action after the documented reactivation procedure with release files verified intact.

---

Source: HelpScout #3456322130
Generated by bug-report-triage (ID: bug-report-triage_6aaf4c4cab58b6.52292839)

Start in classes/Visualizer/Module/Setup.php, especially activate_on_site(), schedule_refresh_db_action(), and unschedule_refresh_db_action(); then inspect Upgrade.php migration methods and index.php Action Scheduler loading. Review tests/test-schedule.php and tests/test-import.php, and reproduce with Action Scheduler 3.9.3 if a WordPress test environment is available. Done should cover activation, deactivation, migration, and both-schedulers-missing scenarios so visualizer_schedule_refresh_db is reliably present after reactivation.