How to search for async actions

[crstauf]

For as_next_scheduled_action() and as_get_scheduled_actions(), how is it specified to only search for async actions?

[crstauf]

Recommend this be added to the documentation for easy, future reference.

[barryhughes]

Hi @crstauf,

This isn't directly supported by as_get_scheduled_actions() but you could possibly use a strategy looking something like this:

// Query for pending actions.
$pending_actions = as_get_scheduled_actions( [
	'status' => ActionScheduler_Store::STATUS_PENDING,
] );

// Reduce to those with a null schedule.
$pending_async_actions = array_filter( $pending_actions, function( ActionScheduler_Action $action ) {
	return is_a( $action->get_schedule(), ActionScheduler_NullSchedule::class );
} );

May I ask, what's the reason you want to do this (just to inform our picture of how the library is being used)?

[crstauf]

@barryhughes I'm using Action Scheduler to get items from an API.

On each page load, a check runs to see if there's a scheduled refresh action; if there's not, then an async action is enqueued (because it's unknown when the last refresh was) and an action is scheduled for the future; both async and scheduled actions have the same hook name (refresh_items).

It is possible that there may be an async action pending, but no scheduled action, in which case I need to schedule an action. Currently I distinguish between an async action and a scheduled action by passing 'async' => true in the async action's parameters, but ideally AS would provide a means for explicitly checking for or retrieving actions by type (async, scheduled, or both).

[barryhughes]

Gotcha.

Is testing the fetched actions, to see if the schedule type is ActionScheduler_NullSchedule (as in my example) a viable solution for you?

My initial thinking is that approach, and/or simple strategies like using naming conventions, are probably sufficient—but I'd be interested in your feedback (we're open to adding new functionality, but we also have to be judicious as each item we add comes with an ongoing maintenance cost—so we have to balance these things with care).

[crstauf]

Ah sorry for not responding to your example. I'll give that a try and let you know.

[crstauf]

@barryhughes Yes, your approach does work. It's certainly not as ideal as as_get_scheduled_actions() and as_next_scheduled_action() handling out of the box, but it does appear to work.

[barryhughes]

Great! I agree it perhaps isn't as 'neat' as native support of some kind might be, but, I'm also a little unsure just how often this sort of thing might be required. I'll apply our votes needed workflow, though, as it may have more traction that I realize.

[crstauf]

@barryhughes What kind of maintenance cost do you see with supporting this? Shouldn't it be as simple as implementing your code into the relevant functions, and then done? I really can't see where maintenance would be needed on a change like this.

[crstauf]

@barryhughes What kind of maintenance cost do you see with supporting this? Shouldn't it be as simple as implementing your code into the relevant functions, and then done? I really can't see where maintenance would be needed on a change like this.

[barryhughes]

Shouldn't it be as simple as implementing your code into the relevant functions, and then done?

Well, we could consider that, but my initial instinct is that although it works well enough at a certain scale, it's not suitable for inclusion in Action Scheduler itself—because the approach I shared relies on iterating across a result set from within PHP.

A different approach would be to form a query that looks for the serialized form of the ActionScheduler_NullSchedule object...but that doesn't feel great, either. Which all together makes me think that to implement this and make it efficient a small schema change is probably needed.

I'm not suggesting that's got an extravagant maintenance cost by itself, but these things add up and the to my mind existing alternatives seem like pretty reasonable alternatives.