Missing parameter on apply_filters( 'pre_as_enqueue_async_action')

[crstauf]

Makes it possible for pre_as_enqueue_async_action callbacks to see if the action about to be created is considered unique.

Fixes #1082.

Testing instructions

Add the following to a mu-plugin file, such as wp-content/mu-plugins/test-pr-1084.php:

<?php

add_filter( 'pre_as_enqueue_async_action', function ( $null, $hook, $args, $group, $priority, $unique ) {
	var_dump( $null, $hook, $args, $group, $priority, $unique );
}, 10, 6 );

Now create a new async action via WP CLI:

wp eval "as_enqueue_async_action( 'foo', [ 'bar' => 'baz' ], 'foobar', true, 100 );"

You should see output similar to the following (whitespace added for readability):

./wp-content/mu-plugins/test-pr-1084.php.php:4:
NULL

./wp-content/mu-plugins/test-pr-1084.php.php:4:
string(3) "foo"

./wp-content/mu-plugins/test-pr-1084.php.php:4:
array(1) {
  'bar' =>
  string(3) "baz"
}

./wp-content/mu-plugins/test-pr-1084.php.php:4:
string(6) "foobar"

./wp-content/mu-plugins/test-pr-1084.php.php:4:
int(100)

./wp-content/mu-plugins/test-pr-1084.php.php:4:
bool(true)

In particular, we expect to see (bool) true for that final entry.

Changelog

Fix - Allows pre_as_enqueue_async_action callbacks to see if the action about to be scheduled should be unique.

[crstauf]

@barryhughes All the failed checks are with Composer. Can you please fix and/or re-run?

[barryhughes]

Re-running again. Not sure why we're having such a spate of fails, but at least those I sampled are clearly unrelated to the change at hand:

Error: file_put_contents(/home/runner/work/action-scheduler/action-scheduler/vendor/bin/phpunit): failed to open stream: No such file or directory

[crstauf]

Re-running again. Not sure why we're having such a spate of fails, but at least those I sampled are clearly unrelated to the change at hand

Thanks, @barryhughes.

[barryhughes]

Thanks, LGTM!

• Added testing instructions and verified the new behavior.
• No back-compat concerns, since we don't consume this filter ourselves (we've previously had cases where third party code independently triggers the same hook, with the original number of parameters, which can potentially lead to problems).
• CI test fails are sporadic and pretty clearly unrelated.