In AS, you'll see the the common stop_the_insanity() function in use: https://github.com/Prospress/action-scheduler/blob/master/classes/ActionScheduler_WPCLI_QueueRunner.php#L118

I had to do something similar for the migration command to prevent the process from being killed by the server.

I added a call to the function here at the end of the loop: https://github.com/Prospress/action-scheduler-custom-tables/blob/master/src/WP_CLI/Migration_Command.php#L71

/*
 *  Clear all of the caches for memory management.
*/
private function stop_the_insanity() {
	global $wpdb, $wp_object_cache;

	$wpdb->queries = array(); // or define( 'WP_IMPORTING', true );

	if ( ! is_object( $wp_object_cache ) ) {
		return;
	}

	$wp_object_cache->group_ops = array();
	$wp_object_cache->stats = array();
	$wp_object_cache->memcache_debug = array();
	$wp_object_cache->cache = array();

	if ( is_callable( $wp_object_cache, '__remoteset' ) ) {
		$wp_object_cache->__remoteset(); // important
	}
}

Things to consider:

• Since the batch number is flexible, do we want to implement a separate counter so memory isn't flushed too much or too little (every 50 - 100 is common).
• The do-while loop ends when $actions_processed is 0, so technically the memory clear would happen unnecessarily a few times.

Action Scheduler 2.2.0 will be adding a new 'action_scheduler_pre_init' hook, added via woocommerce/action-scheduler#221.

This helps address issues found in #49 with the current dependency check, where it will only work if Action Scheduler Custom Tables is activated after the plugin loading Action Scheduler.

• Replace the use of 'plugins_loaded' with 'action_scheduler_pre_init'
• Update dependency requirement to 2.2.0 (or whichever version of Action Scheduler introduces the 'action_scheduler_pre_init' hook

We added a bunch of things to Action Scheduler, mostly around the admin UI, so that it could fully handle custom data stores, like this one.

Because of that, and because we rely on certain methods only available in AS 2.1.0 and newer, like those added in woocommerce/action-scheduler@bca46a8, this plugin should be updated to require AS 2.1.0 to be active before loading itself.

This can be done either by checking for the existence of a method like action_scheduler_register_2_dot_1_dot_0(), or by using ActionScheduler_Versions::get_versions() (which has existed since AS 1.0.0).

While running 3 queues of scheduled actions (with a small batch size of 5 actions) via WP CLI, I enountered the following deadlock:

WordPress database error Deadlock found when trying to get lock; try restarting transaction for query
UPDATE wp_actionscheduler_actions SET attempts = attempts+1, status='in-progress', last_attempt_gmt = '2018-05-10 10:31:56', last_attempt_local = '2018-05-10 06:31:56' WHERE action_id = 803045 made by
include('phar:///usr/local/bin/wp/php/boot-phar.php'),
include('phar:///usr/local/bin/wp/php/wp-cli.php'),
WP_CLI\bootstrap,
WP_CLI\Bootstrap\LaunchRunner->process,
WP_CLI\Runner->start,
WP_CLI\Runner->_run_command_and_exit,
WP_CLI\Runner->run_command,
WP_CLI\Dispatcher\Subcommand->invoke,
call_user_func,
WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure},
call_user_func,
ActionScheduler_WPCLI_Scheduler_command->run,
ActionScheduler_WPCLI_QueueRunner->run,
ActionScheduler_Abstract_QueueRunner->process_action,
Action_Scheduler\Custom_Tables\DB_Store->log_execution

Screenshot: https://cl.ly/262n1x3m1E3Z

Hi,

while working on a site using this tables, I found the code where the ActionScheduler_TimezoneHelper::set_local_timezone is used. The $date that is passed there seems not be used because the set_local_timezone (https://github.com/woocommerce/action-scheduler/blob/master/classes/abstracts/ActionScheduler_TimezoneHelper.php#L18-L32) does not pass $date by reference.

Wouldn't the $date_gmt and $date_local be the same here:
https://github.com/Prospress/action-scheduler-custom-tables/blob/master/src/DB_Logger.php#L28-L30 ?

Maybe I am wrong here, but just checking to see if I understand it correctly.

I activated the master-branch version of this plugin on a test site that hadn't yet been migrated. This error was a nice surprise :)

Stack trace:

Fatal error: Uncaught Error: Cannot call abstract method ActionScheduler_Logger::init() in /wp-content/plugins/action-scheduler-custom-tables/src/DB_Logger.php:92
Stack trace:
#0 /wp-includes/class-wp-hook.php(284): Action_Scheduler\Custom_Tables\DB_Logger->init()
#1 /wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array)
#2 /wp-includes/plugin.php(453): WP_Hook->do_action(Array)
#3 /wp-settings.php(467): do_action('init')
#4 /wp-config.php(11): require_once('/wp-set...')
#5 /wp-load.php(37): require_once('/wp-con...')
#6 /wp-admin/admin.php(31): require_once('/wp-loa...')
#7 /wp-admin/plugins.php(10): require_once('/wp-adm...')
#8 {main}
  thrown in /wp-content/plugins/action-scheduler-custom-tables/src/DB_Logger.php on line 92 

Introduced here: b0fbfcd.

Resolved for now by using the tagged 1.0.0-beta version (probably should have done that to start).

See #12 tests.

Is this just a 'beta' in terms of migration/compatibility with existing active plugin users,
or are there still unfinished/untested features that new installs need to worry about?

At the moment, canceled actions (which use post status trash with ActionScheduler_wpPostStore) are not being migrated to the new data store. This is likely intentional, but worth double checking.

It may also make sense for these actions to be migrated so that they are available for debugging purposes.

Caught after attempting to update Subscriptions to 2.3-RC-2 on a site with this plugin active:

Fatal error: Declaration of Action_Scheduler\Custom_Tables\Hybrid_Store::stake_claim($max_actions = 10, ?DateTime $before_date = NULL) must be compatible with ActionScheduler_Store::stake_claim($max_actions = 10, ?DateTime $before_date = NULL, $hooks = Array, $group = '') in /srv/bindings/bb73e9145a7a4536889a5adbcdba2a20/code/wp-content/plugins/action-scheduler-custom-tables/src/Hybrid_Store.php on line 0

The abstract ActionScheduler_Store::stake_claim() function and classes overriding that function (DB_Store & Hybrid_Store) will need to be updated to include the $hooks = array() and $group = '' args.

The last_attempt_local and last_attempt_gmt values are being set to 0000-00-00 00:00:00 when migrating a completed action. They should instead be set to the post_modified and post_modified_gmt column values for the action being migrated.

This ultimately leads to all completed actions being deleted soon after migrating, because ActionScheduler_QueueCleaner::delete_old_actions() runs a query to find actions with a modified <= 31 days ago, which 0000-00-00 00:00:00 will always be.

The last remaining bottleneck I've seen on live sites when using AS with custom tables are queries for actions for a specific set of args. As args are often used to link an action to another object, like a subscription or membership, this is a common use case.

While this "bottleneck" is minor, a few seconds even on large sites, it can add up.

For example, when a subscription renewal is processed, the subscriptions status is first changed to on-hold, after which all scheduled actions for that subscription are unscheduled, which includes both a query to unschedule the next scheduled, and check if there are any others scheduled that need to be unscheduled (code: https://cl.ly/18450k122y0l )... then if the renewal payment is processed successfully, in the same request, all the subscriptions scheduled actions, like expiration, next payment etc. will be scheduled again... but only if there isn't already one scheduled, which requires another query on scheduled actions for that subscription, for each action to be scheduled. This means even a few seconds can add up to 10-20 seconds quite easily. While this specific example could be addressed by refactoring in Subscriptions, that refactoring is unnecessary when args is indexed, because the query time drops to 0.15 seconds.

Indexes on fulltext column types aren't ideal. And really, the args column doesn't need to be a fulltext. It's only set to that type for backward compatibility with the post_content column which was previously used to store args.

Changing the column to a varchar(255) type won't break the plugins I've seen using AS. However, we should check other use cases through GitHub code search, and also by adding a notice to AS core to prepare for this change (see woocommerce/action-scheduler#185 for that).

In order to be able to add a Search box to the new Admin UI in Action Scheduler core (see woocommerce/action-scheduler@dfd741f ), it was necessary to add a 'search' query param to ActionScheduler_Store::query_actions() (see woocommerce/action-scheduler@67d2d55 ).

For now, this query param will be used to search the action's hook, args and claim ID. It could be extended to search group or other fields, but those 3 fields were all that was requirements to maintain backward compatibility with the old Admin UI (which implemented the query filtering itself directly on post queries instead of using the ActionScheduler_Store).

This new filter needs to be honoured in Hybrid_Store::query_actions() and DB_Store::query_actions() as well.

Once the custom_tables branch merges into master for Action Scheduler, remove AS_VERSION global from travis.yml

Hi;

I've been tracking this repo (and the main action scheduler repo as well) for a while now.

I'm currently using https://github.com/A5hleyRich/wp-background-processing in the Google Product Feed extension (https://woocommerce.com/products/google-product-feed) to carry out background processing. When it works, this works well. However - it's proven to be quite problematic and erratic for a number of customers so I'm looking for alternatives.

I looked at action scheduler, however since the plugin can generate a large number of background jobs, I'm not comfortable with it using CPT as the storage which let me to this repo which seems perfect.

I notice that the composer.json claims it's version 1.0.0, but the plugin header itself declares itself as 1.0.0-dev. So, I just wanted to reach out and get a view on the stability of the package - would you consider it production ready / near production ready? If not, are you still actively working on it?

If Slack is a better medium for discussion - feel free to reach out there, I'm on the a8c or woocommerce community slacks if that's useful.

Once woocommerce/action-scheduler@bca46a8 is merged with woocommerce/action-scheduler#191, a bunch of duplicate code in DB_Logger can be removed.

Once solutions for woocommerce/action-scheduler#121 and woocommerce/action-scheduler#160 are implemented, create an equivalent for the custom table store.

Note: this was initially opened in AS repo with woocommerce/action-scheduler#178, but I'm 90% sure it's related only to custom tables now, so I'm opening it here instead.

The date/time displayed against log entries on the admin list table always show current time, not the time of the actual events.

For example, here are the log events displayed for the same scheduled action on the admin page loaded about 10 minutes apart:

1. Load at 2018-07-17 04:29:15 UTC: https://cl.ly/3p0V0u430s2b
2. Load at 2018-07-17 04:38:43 UTC: https://cl.ly/0T1I0r1y0o1t

Notice the times display on each change depending on the page load time, and all entries display the times the page was loaded.

I noticed this on ticket https://secure.helpscout.net/conversation/555708450/7375?folderId=1524436

I've also seen it on other sites.

There is an incorrect boolean check here

https://github.com/Prospress/action-scheduler-custom-tables/blob/d9a7a7a9a41af09b576613888ee2804bb1f69ea9/src/Plugin.php#L146-L150

Causing the plugin NOT to load when the dependencies ARE met.
The boolean logic needs to be reversed.
Currently when the deps are not met, the plugin will load, and when they are met, the plugin will not load, but will not display any notices because the deps are all met!

When creating a new action in the DB_Store class, we don't do any checking to verify that the ID is valid, or that no error occurred. When an error occurs, I've found that the ID will be set to 0, which is one way to check that the insertion was successful. We should also be able to check $wpdb->last_error.

To match woocommerce/action-scheduler#139 (if it's merged).

As counterpart to woocommerce/action-scheduler#165

I'm seeing the following on after installing Custom Tables and running the migration on a staging copy of a live site:

PHP Fatal error: Uncaught Error: Call to undefined function Action_Scheduler\\Custom_Tables\\Migration\\wc_next_scheduled_action() in /wp-content/plugins/action-scheduler-custom-tables/src/Migration/Migration_Scheduler.php:59
Stack trace:
#0 /wp-content/plugins/action-scheduler-custom-tables/src/Plugin.php(79): Action_Scheduler\\Custom_Tables\\Migration\\Migration_Scheduler->is_migration_scheduled()
#1 [internal function]: Action_Scheduler\\Custom_Tables\\Plugin->schedule_migration()
#2 /wp-includes/class-wp-hook.php(284): call_user_func_array(Array, Array)
#3 /wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters('', Array)
#4 /wp-includes/plugin.php(453): WP_Hook->do_action(Array)
#5 /wp-includes/load.php(679): do_action('shutdown')
#6 [internal function]: shutdown_action_hook()
#7 {main}
 thrown in /wp-content/plugins/action-scheduler-custom-tables/src/Migration/Migration_Scheduler.php on line 59

• implement new methods required by ActionScheduler_Store
• remove validate_sql_comparator() from DB_Store as it is ActionScheduler_Store now

There is an admin notice to display at the top of the list table while the custom tables migration is in progress.

That can be updated here once the new admin view is ready.

In a similar vein to #36, while we're changing the DB structure, we may wish to enforce a 191 char limit for the hook column to ensure hooks can be indexed in their entirety.

IMO, 191 is still more than enough chars for a hook, arguably too many really. The only reason it's set to 255 atm is because of the legacy from the post store. So it should be OK and reasonable to change (either to 191, or even lower).

Any objections?

If we decide to reduce the length', we'll also need a similar warning in AS 2.1.0 like the one added with woocommerce/action-scheduler#187.