Action failed for array_merge error, but only sometimes

Resolved CK MacLeod
(@ck-macleod)

6 months, 1 week ago
I am running Action Scheduler (initialized via WooCommerce) and have successfully created and run numerous custom actions. In a rather complex implementation, though somewhat straightforward in terms of AS usage), I am using as_schedule_single_action and the identical code results in a successfully completed action for one run, but immedialy results in failure for the second.

The basic code I’ve been using for the action that consistently succeeds in the one case, and consistently fails in the second is this (though I’ve experimented with several minor variations):
```
as_schedule_single_action( $event_date - MONTH_IN_SECONDS - ( get_option( 'gmt_offset' ) * HOUR_IN_SECONDS ), 'gbesu_tribe_events_one_month_notification', array( $event_id ), $event_id . '-bp_event_in_one_month' ) ; 
```
The logged failure is as follows:

2025-08-06 16:31:16 +0000 action failed via Admin List Table: array_merge(): Argument #1 must be of type array, null given

The only argument being passed is listed in the Admin table as an array, and in the same manner that the successful actions based on the identical code are also listed.

I’ve looked through Action Scheduler as well as WordPress Core (WP_List_Table), and can see where the error message is generated in the former, but I can’t find what looks like a likely “array_merge” for the message anywhere, and remain mystified as to why the identical code produces failures in one place, but not in another.
The only differences between the two actions would seem extraneous to the AS actions. The arguments happen to refer to post ids.
Similarly, there are two actions being run on the same post_id, where one fails and the other succeeds.

The code that succeeds consistently looks like this:
```
as_schedule_single_action( $event_date - DAY_IN_SECONDS - ( get_option( 'gmt_offset' ) * HOUR_IN_SECONDS ), 'gbesu_clear_notifications', array( 'bp_event_in_one_month', $related_course_id ), $event_id . '-bp_event_in_one_month' ) ;
```
Since I’ve been unable to isolate the exact location of an array_merge error, I’ve tried various alternatives – like running only one version, switching action titles in otherwise identical as_schedule_single_action functions, or switching the arguments arrays, without success.

At this point, I’m mystified and am running out of things to try.

Viewing 5 replies - 1 through 5 (of 5 total)

Plugin Support Shameem – a11n
(@shameemreza)

6 months ago
Hi @ck-macleod

Thanks for reaching out about this puzzling issue.

From what I found, the error you’re seeing, arraymerge(): Argument #1 must be of type array, null given occurs when Action Scheduler tries to retrieve and execute your stored actions. The action arguments can get corrupted during storage or retrieval, causing jsondecode() to return null instead of an array.

This explains why identical code sometimes works but fails other times. It depends on whether the data gets corrupted during the process.

Here’s what you can do:
- Validate your arguments before scheduling to ensure they’re clean:
```
   $clean_event_id = absint( $event_id );
   $args = array( $clean_event_id );
```
- Add error handling in your action hook (gbesu_tribe_events_one_month_notification) to manage any invalid data gracefully.
- Clean up any corrupted actions in your database to prevent future issues. You can check your wp_actionscheduler_actions table for any actions with invalid JSON in the args column and remove the failed ones.
For prevention, consider adding logging to track when actions are scheduled and fail, and use simpler argument structures to minimize JSON corruption risk.

Try these steps and let me know how it goes.
Thread Starter CK MacLeod
(@ck-macleod)

6 months ago

Hi, thanks for your reply, but I don’t think it points to much of use, I’m sorry to say.

As for your suggestions, before I get to some new mystifying results:
1) There isn’t a lot of input to validate, and it’s hard for me to see why it would be relevant. Still, I validated what I could, and it made no difference.
2) See above, there aren’t many things that COULD go wrong in the action, and, anyway, if there were significant errors, then I don’t see how the action would fail due to an error yet still find its way into the AS Pending page.
3) Similarly, there isn’t much TO find in the table you reference. In all cases, the only “action” entries are very simple: an id number in brackets. Nothing shows up in visually inspecting the database that looks wrong.

Now, as for the new mystifying info, the situation has changed in one respect. We have the identical or nearly identical code and options (themes and plugins) running on both a staging site and a production site. In order to test out your above suggestions to the extent that I could, I discovered that the very same type of action all of the leftover actions as well as new ones completed successfully. This new set of actions to test were either new actions identical to ones that had failed previously, or were from the very same sets of actions which had consistently been failing two days ago.

I do not know what environmental factors might be contributing to such differences. I returned to the live site and re-tested some leftover actions from the ca. 2-day-old “failure groups,” and they again failed. I’ll try again later, just on the offchance that something has changed again…
Plugin Support Shameem – a11n
(@shameemreza)

6 months ago
Hi @ck-macleod

Thanks for the detailed follow-up. Since the exact same actions work on staging but fail on production, and previously failing actions sometimes start working spontaneously, you are likely dealing with an environmental issue or race condition rather than corrupt data.

A few technical points to consider:
- The error specifically mentions action failed via Admin List Table . This is significant because manual execution follows a different code path than scheduled execution. The array_merge error is likely occurring in the manual execution flow.
- Check for these differences between your staging and production:
  - PHP version and memory limits.
  - MySQL/MariaDB version and settings.
  - OpCache or other caching mechanisms.
  - Load and concurrent processes.
- Some plugin might be altering the global state between when you click run and when the action executes. Try these tests:
  - Temporarily disable plugins that hook into init, admin_init, or modify global $wpdb
  - Run the action via WP-CLI instead of the admin interface (wp action-scheduler run <id>)
- If the problem resolves after some time without changes, it suggests a transient state issue in the environment.
Would you be able to check your PHP error logs on production around the time of failure? That might reveal additional errors that occur before the array_merge failure.

This type of intermittent issue is challenging, but I’m happy to continue working through it with you.
Thread Starter CK MacLeod
(@ck-macleod)

5 months, 3 weeks ago
@shameemreza

I thought I should catch you up and clarify a couple of things, especially since I expect I’ll be giving up on this avenue for achieving what we need to achieve. I’ve spent many more hours than expected on this one aspect of a much more complex application, and need to move on.

Since the exact same actions work on staging but fail on production, and previously failing actions sometimes start working spontaneously, you are likely dealing with an environmental issue or race condition rather than corrupt data.

I should make it clear that I continue to get inconsistent results on staging – far too inconsistent to depend on even if I could re-produce the identical environmental conditions elsewhere.

The error specifically mentions action failed via Admin List Table . This is significant because manual execution follows a different code path than scheduled execution. The array_merge error is likely occurring in the manual execution flow.

I’ve also tested initiation by automated methods, and receive versions of the same error referencing the appropriate context, like “Async.”

Check for these differences between your staging and production:
PHP version and memory limits.
MySQL/MariaDB version and settings.
OpCache or other caching mechanisms.
Load and concurrent processes.

Both installations are now running PHP 8.3. The dysfunction also occurred under 8.1. Memory limits are lower at staging than production, but at both installations very high. Execution time limits for testing have ranged from 60 to 600 seconds. In any event, they don’t seem relevant, since the “Failed” response occurs almost instantly at least during manual initiation.

Conforming MySql identically between staging and production runs up across limitations with our host, who assures us they are irrelevant. However, since, even in the best case, functionality is too compromised for implementation in a production environment, making the attempt would be an academic exercise.

Would you be able to check your PHP error logs on production around the time of failure? That might reveal additional errors that occur before the array_merge failure.

No additional PHP errors found.

For this element of the larger application, scheduling and managing discrete non-recurrent notification actions at set points in the future, I’ve switched back to basic WP Cron, and results are so far consistent. I’m sorry we couldn’t get this solved, as I’ve found Action Scheduler more reliable and capable than basic WP Cron for other applications (especially frequently recurring ones).
- This reply was modified 5 months, 3 weeks ago by CK MacLeod.
Plugin Support Shameem – a11n
(@shameemreza)

5 months, 3 weeks ago

Hi @ck-macleod,

I completely understand your decision to move forward with WP Cron. You’ve done incredibly thorough debugging, and these types of inconsistent, environment-dependent issues can be real time sinks.

It’s particularly puzzling that the issue is inconsistent even within the same environment (staging). This kind of non-deterministic behavior is one of the most challenging to debug, and you’re right that it makes the solution unsuitable for production regardless.

Thank you for taking the time to share everything so thoroughly. Your detailed investigation will definitely help if we encounter similar reports in the future. I’m glad WP Cron is working consistently for your discrete notification scheduling needs.

If you do use Action Scheduler for other recurring tasks where it’s been reliable for you, and run into any issues there, we’re here to help.

Viewing 5 replies - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.