Hi,
I wanted to report a conflict between ATUM and other plugins that use Action Scheduler for heavy background processing.
ATUM registers two filters that apply globally to all Action Scheduler jobs, not just its own:
action_scheduler_queue_runner_time_limit → set to 120 seconds
action_scheduler_queue_runner_concurrent_batches → set to 3
Both run at priority 10 with no condition checking which hook is currently running, meaning they affect every plugin on the site using Action Scheduler.
Important clarification on how the timeout manifests: when ATUM's 120-second PHP execution limit kills a batch process, Action Scheduler doesn't immediately mark it as failed — it waits for its own separate claim timeout (300 seconds) before updating the database record. This means the failure appears in logs as "action marked as failed after 300 seconds" which is misleading — the batch actually died at 120 seconds due to ATUM's limit, not at 300.
In my case I'm running AdTribes Product Feed Elite on a catalog of ~ 18 000 products. Feed generation batches were consistently failing, and after tracing through the Action Scheduler logs and plugin source code I identified ATUM's global filter overrides as the root cause. The 3-concurrent-batch limit was also slowing down unrelated scheduled tasks across the site.
My current workaround: add both filters at priority 99 to override ATUM's values. This shouldn't be necessary.
Suggested improvements:
Scope these limits to ATUM's own hooks only — check which action is currently running before applying the limit, rather than returning a fixed value unconditionally.
Make the limits configurable in ATUM's settings UI. The filters atum/queues/as_time_limit and atum/queues/as_concurrent_batches exist but are developer-only with no UI exposure.
Register at priority 1 instead of 10 so other plugins can easily override without needing to know about the conflict.
Happy to provide further technical details. Thanks for a great plugin otherwise.