-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CRITICAL Uncaught InvalidArgumentException: The group "rocket-rucss" does not exist. #972
Comments
@alewolf Thanks for reporting the issue. By default Action Scheduler does not filter by groups when running actions. However, if you install WP Crontrol you may be able to find the offending cron job and delete it. If you have recently removed or deactivated a plugin then look for a cron job associated with that plugin. We'll leave this issue open as a reminder to evaluate how to handle this exception. |
@rrennick This was reported to me by a user of my plugin, the Pixel Manager for WooCommerce I can't replicate the error because it doesn't occur on my installs. The way the Action Scheduler works, it can be a third-party plugin triggering the error. But the Action Scheduler is executed from the Pixel Manager folder because I pack the newest version, so the error log shows That's why I get the support requests. I assume many other users are blaming the Pixel Manager without telling me. I'm considering downgrading the Action Scheduler version in the Pixel Manager to one version lower than the one packed with WooCommerce to avoid that problem and redirect support requests to WooCommerce that way. But that would not be a good solution on a larger scale. |
@alewolf Thanks for the quick follow up. Can you ask one of the customers for their Woo SSR? Hopefully the rocket-rucss slug will point to an inactive plugin in their install. |
@rrennick What do you mean by "Woo SSR" ? |
@alewolf @rrennick I'd suggest asking customer to contact our Support Team, I can see that we had one case like this in the pas but we were not able to reproduce this problem. If it's reproducible, it would be great to provide us access to this website. |
Hi I am the customer with the issue do you need my website link? |
@sagestephens (and @alewolf), we're a little confused as to what is happening here. Flipping the backtrace upside down, here are how things seem to be unfolding:
☝🏼 We basically start here, inside WP's cron code. This means WordPress is in the middle of processing any scheduled events that have been registered and, in this case, that seems to mean the Action Scheduler queue runner event.
☝🏼 I think we can skip a few entries until we get here. Note that this method only accepts one parameter (the context, which in this case will be
☝️ Next, the
☝️ Here we are, staking a claim and the only information we pass is the number of actions we want to claim (25, based on the backtrace).
☝️ Closing in on the point-of-failure, when we try to claim the actual actions the default behavior would be to not specify any group (see code here) yet the backtrace tells us This is what's confusing us (ie, where is |
We have another report of the same issue in https://wordpress.org/support/topic/customers-is-not-working/#post-17011606
|
Thanks, @PanosSynetos. I somehow missed (or misinterpreted) @piotrbak's note. Given this is the result of a custom queue runner, it seems appropriate to close this (the raised exception does not seem inappropriate to me). For anyone else experiencing this problem, please do reach out to the WP Rocket team. |
May I ask why here:
$create_if_not_exists argument is false? |
Hi @engahmeds3ed, This method is responsible for claiming actions. So, I'd flip the question around: if the specified group or groups do not already exist, and so there are no actions to be claimed, why would we create one or more empty groups? It doesn't feel to me like a step the claiming process should take. Building on that, my initial thoughts are that it seems reasonable for us to avoid creating empty groups and also that it is the responsibility of any custom code calling this method to anticipate and catch any exceptions it might throw. Let me know your thoughts (though, Ron may also have valuable input to add on this one). |
I agree. We should not be creating groups during the claim process. |
That's a valid point, thanks @barryhughes @rrennick for taking time explaining that. |
After some investigation about this issue, let me share with u my findings so u can decide if we need to fix that in action Scheduler's core or not. Assume we have a custom queue runner like this one and as u see, there we are not setting the store object so it's null exactly like the default queue runner here So Based on that code, both runners will share the store instance (because it's singleton design pattern). What happens here is that the custom runner is running before the default runner passing the group to the store and based on that code that was added in this pull request you are setting the group item inside claim_filters and as we use the same object for store in both queue runners, the group will be kept the one that added in the custom queue runner. You can also check the following full backtrace:
what do u think @barryhughes @rrennick ? |
I believe WP Cron is calling both of CRON schedules in the same thread/request. List of crons are being fetched here: and then Core is looping on them here: I believe that's because both of them are running every minute and used The trace is showing that. |
That PR only changes the WP CLI |
@alewolf Also, you are getting sidetracked from the root issue which is that the AS group does not exist. The custom runner is trying to claim actions from that group. |
u changed in the store class here:
I know exactly what I'm saying, I'm not getting sidetracked at all, I'm very clear with full trace and every line of code. Anyway, I'll stop here and fix this in our side by creating our own store, just consider this conversation if u want/need. Thanks for ur time. |
The WP CLI classes are only loaded when the process is WP CLI. |
On some installs, our users get a
CRITICAL Uncaught InvalidArgumentException: The group "rocket-rucss" does not exist.
error.This might be related to #882 and #970.
This should be fixed or a safeguard built in to prevent the critical error.
Here's the error log:
The text was updated successfully, but these errors were encountered: