Updated woocommerce => "There has been a critical error on your website."

angular12 commented 4 years ago

Upgraded woocommerce today because there was 5gigs of error messages generated by woocommerce in a week. The upgrade disabled the entire website. "There has been a critical error on your website." Can't even access the dashboard.

Searching I found the same errors reported from 3 months ago?!? and yet the current woocommerce update is still nuking websites? Wow.

Is it still the solution to install an entire new wordpress installation and install woocommerce there and then find and copy over "4 tables" (name of each please) Is that still the solution today (months later)?

Also am i supposed to do this on a different domain or fine to just start from scratch on live domain. I have a backup but I can't do a restore because your update crippled the wordpress installation.

Company site is down in the meantime.

"You will have to create in all versions 4.0+ to create the 4 tables of ActionScheduler if they do not exist. Probably 90% of v.3+ users are having a problem they can't do anything about unless the tables do exist if they copy from newly installed 4.0+ on a new raw Wordpress installation."

Fatal error: Uncaught RuntimeException: Error saving action: Error saving action: Table '[user]_mywpdb.wp_actionscheduler_actions' doesn't exist in /home/[user]/public_html/wp-content/plugins/woocommerce/packages/action-scheduler/classes/migration/ActionScheduler_DBStoreMigrator.php:44 Stack trace: #0 /home/[user]/public_html/wp-content/plugins/woocommerce/packages/action-scheduler/classes/data-stores/ActionScheduler_HybridStore.php(242): ActionScheduler_DBStoreMigrator->save_action(Object(ActionScheduler_Action), NULL) woocommerce/woocommerce#1 /home/[user]/public_html/wp-content/plugins/woocommerce/packages/action-scheduler/classes/ActionScheduler_ActionFactory.php(177): ActionScheduler_HybridStore->save_action(Object(ActionScheduler_Action)) woocommerce/woocommerce#2 /home/[user]/public_html/wp-content/plugins/woocommerce/packages/action-scheduler/classes/ActionScheduler_ActionFactory.php(84): ActionScheduler_ActionFactory->store(Object(ActionScheduler_Action)) woocommerce/woocommerce#3 /home/[user]/public_html/wp-content/plugins/woocommerce/packages/action-scheduler/f in /home/[user]/public_html/wp-content/plugins/woocommerce/packages/action-scheduler/classes/migration/ActionScheduler_DBStoreMigrator.php on line 44

Prerequisites

[x] I have searched for similar issues in both open and closed tickets and cannot find a duplicate
[ ] The issue still exists against the latest master branch of WooCommerce on Github (this is not the same version as on WordPress.org!)
[x] I have attempted to find the simplest possible steps to reproduce the issue
[ ] I have included a failing test as a pull request (Optional)

Steps to reproduce the issue

1. 2. 3.

Expected/actual behavior

When I follow those steps, I see...

I was expecting to see...

Isolating the problem

[ ] This bug happens with only WooCommerce plugin active
[ ] This bug happens with a default WordPress theme active, or Storefront
[ ] I can reproduce this bug consistently using the steps above

WordPress Environment

``` Copy and paste the system status report from **WooCommerce > System Status** in WordPress admin here. ```

tammullen commented 4 years ago

Hi @angular12

Thank you for reporting the issue. Action Scheduler is being developed in another repository: https://github.com/woocommerce/action-scheduler. I am going to move your bug report there so that the right team could take a look further.

capuderg commented 4 years ago

Hi!

We are using Action Scheduler in our plugin WP Mail SMTP and some of our users have experienced this fatal error as well. Here is a screenshot of the stack trace: as-error

This error comes up when the DB can't create the needed DB tables (for some unknown reason). We created this docs page for the users that experience this issue and this resolves the problem for some, but not for all.

We enqueue the AS library as it's described in on the usage page (on 'plugins_loaded' hook with negative priority: -10). This works well for the majority of our users, but the ones with DB limitations will get this fatal error above right after updating of activating our plugin.

My suggestion would be: Could the \Action_Scheduler\Migration\Scheduler or \Action_Scheduler\Migration\Controller class first check if the tables are ready, before saving an action? If the tables are not created, try to create them and if that does not resolve the issue, display an admin notice to the user, so he knows something is wrong.

Thank you very much for creating and maintaining this library!

ChipMinder commented 3 years ago

Hi!

We are using Action Scheduler in our plugin WP Mail SMTP and some of our users have experienced this fatal error as well. Here is a screenshot of the stack trace:

This error comes up when the DB can't create the needed DB tables (for some unknown reason). We created this docs page for the users that experience this issue and this resolves the problem for some, but not for all.

We enqueue the AS library as it's described in on the usage page (on 'plugins_loaded' hook with negative priority: -10). This works well for the majority of our users, but the ones with DB limitations will get this fatal error above right after updating of activating our plugin.

My suggestion would be: Could the \Action_Scheduler\Migration\Scheduler or \Action_Scheduler\Migration\Controller class first check if the tables are ready, before saving an action? If the tables are not created, try to create them and if that does not resolve the issue, display an admin notice to the user, so he knows something is wrong.

Thank you very much for creating and maintaining this library!

@rrennick @capuderg Any updates on this issue?

rrennick commented 3 years ago

My suggestion would be: Could the \Action_Scheduler\Migration\Scheduler or \Action_Scheduler\Migration\Controller class first check if the tables are ready, before saving an action?

That's solution is not practical. If every plugin that had a custom table checked for the table's existence before using it most sites would be extremely slow.

@kumarec I apologize. In the other issue I intended to give you a link to https://github.com/woocommerce/action-scheduler/issues/587#issuecomment-658168773. Can you let me know the results of doing that?

capuderg commented 3 years ago

@rrennick yeah, I agree that checking DB tables on each load would be too much...

I've taken a deeper look at this issue and I could reproduce it by revoking all permissions and granting only SELECT,INSERT,UPDATE,DELETE for the MySQL DB user used in the wp-config.php of my WP test site.

I've installed a fresh copy of WP with the DB user having all permissions/privileges. Then I executed these commands on the MySQL:

REVOKE ALL ONwp_testdb.* FROM 'example_db_user'@'localhost';
GRANT SELECT,INSERT,UPDATE,DELETE ONwp_testdb.* TO 'example_db_user'@'localhost';
flush privileges;

After that, I activated our WP Mail SMTP plugin (you could also activate AS plugin or any other plugin that uses AS library) and you should see the fatal error reported above:

Fatal error: Uncaught RuntimeException: Error saving action: Error saving action: Table '[user]_mywpdb.wp_actionscheduler_actions' doesn't exist in ...

The \ActionScheduler_DBStoreMigrator::save_action method throws the \RuntimeException which is not caught by any of the parent methods in the stack. It would be very nice if it would be caught in let's say \Action_Scheduler\Migration\Controller::schedule_migration method where the $this->migration_scheduler->schedule_migration(); is called. In the catch statement, an admin notice with the error message could be registered (maybe restricted to your tools page only)?

I could also prepare a PR if you want?

This would allow the users to not experience the fatal error and they would be able to find the info as to what went wrong on the AS tools page (in the admin notice).

What do you think about this idea?

rrennick commented 3 years ago

I could reproduce it by revoking all permissions and granting only SELECT,INSERT,UPDATE,DELETE for the MySQL DB user used in the wp-config.php of my WP test site.

No plugin would be able to create tables with those permissions.

rrennick commented 3 years ago

The \ActionScheduler_DBStoreMigrator::save_action method throws the \RuntimeException which is not caught by any of the parent methods in the stack.

This is probably something we should address. However, we'd need to check for other instances where the exception isn't caught.

slaFFik commented 3 years ago

No plugin would be able to create tables with those permissions.

Correct. But there is a valid scenario: All the development and plugins activations (and thus DB tables creation) is done on a special STAGING server, and then migrated to a PROD server where MySQL user does not have non-essential capabilities. Creating tables regularly is needed only on WP Multisite installations (another beast of its own) and when plugins are activated/configured on a site. If none of that is done on a PROD server - CREATE capability is not needed for a MySQL user.

rrennick commented 3 years ago

But there is a valid scenario:

Agreed. I've seen this type of thing in the past. But for the scenario we are discussing, the AS tables should be created in staging to be migrated over.

capuderg commented 3 years ago

These are just steps on how you can make this issue reproducable. The minority of AS users that experience this issue are probably on some special configurations or are blocked by some other MySQL restrictions, like #587, ...

But yeah, catching the exception (discussed above) would resolve the fatal error and letting the user know what the error is in some way or another would be beneficial, so the user knows in which way to investigate to resolve his issues.

rrennick commented 3 years ago

an admin notice with the error message could be registered (maybe restricted to your tools page only)?

I forgot to mention that there is already a notice there. The AS admin screen checks to see if all the tables are present.

capuderg commented 3 years ago

Yes, if I'm not mistaken, there are two notices:

Action Scheduler migration in progress. The list of scheduled actions may be incomplete.
It appears one or more database tables were missing. Attempting to re-create the missing table(s).

In this specific case (OP error), these two notices are not accurate. The migration is not running and there is no attempt to re-create the missing tables since the error happens before those two things can register.

rrennick commented 3 years ago

there is no attempt to re-create the missing tables since the error happens before those two things can register.

AS attempts to create the tables as part of the flow for adding that notice to the dashboard.

The migration is not running

The migration is "in progress" but not progressing due to the lack of the table(s).

barryhughes commented 3 years ago

Closing: this issue is one year old and has mostly been dormant for the the last 10 months, or thereabouts. It also seems to relate to a problem associated with the data store migration (triggered by 3.0.0) which most users have now moved past.

Those things considered, at this point in time it's probably best we focus on other areas (though, we can definitely apply learnings from this experience to any similar future work).

angular12 commented 3 years ago

I haven't updated my wordpress software in over a year while waiting for this bug to be resolved.

You have closed the issue, does this mean I can update my wordpress plugins without the wordpress installation failing completely?

Loren Hall Founder & CEO InSites Web Services www.insiteswebservices.com 866-OPT-RANK / 503-515-6389

[image: https://www.google.com/partners/agency?id=7809898542] https://www.google.com/partners/agency?id=7809898542 https://twitter.com/IWS_Marketing https://www.facebook.com/IWS.Internet.Marketing

On Thu, Jun 24, 2021 at 10:56 AM Barry Hughes @.***> wrote:

Closing: this issue is one year old and has mostly been dormant for the the last 10 months, or thereabouts. It also seems to relate to a problem associated with the data store migration (triggered by 3.0.0) which most users have now moved past.

Those things considered, at this point in time it's probably best we focus on other areas (though, we can definitely apply learnings from this experience to any similar future work).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/woocommerce/action-scheduler/issues/577#issuecomment-867839971, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH33PR2FISNBAIN5CBKWWOLTUNWVLANCNFSM4N4HHJIA .

barryhughes commented 3 years ago

@angular12—thanks for reaching out: that is a useful update for us.

You have closed the issue, does this mean I can update my wordpress plugins without the wordpress installation failing completely?

Every case is different, but if for example the previous failure occured because of a lack of MySQL permissions (ie, Action Scheduler could not create the required tables) and if that has not changed since then, it's likely the same problem will occur again.

Also—and I should have linked to this in my last reply, apologies for not doing so—but I'll note that #653 (which relates to this and proposes introducing an extra safety check) remains open.

I haven't updated my wordpress software in over a year while waiting for this bug to be resolved.

If we implement #653 (which hasn't happened yet) then we should avoid a site crash, but there will still be a fundamental problem in that the database tables Action Scheduler expects to exist will still be missing, so what I'd propose is either updating from a staging environment first and then copying the new tables across to production (as highlighted in the above discussion), or else creating those same tables in production ahead of updating.

Alternatively, you could continue to use the legacy data-store (which relies on WordPress's own posts/comments tables) and avoid the migration. The downside to that is you will not be able to take advantage of the performance enhancements introduced by the DBStore implementation.

Action Scheduler DBStore Tables

Action Scheduler now defaults to using the following 4 tables instead of using the post and comment tables as it did previously (note: though I'm using the wp_ prefix here, that may be different in some cases, so please adapt as needed):

- `wp_actionscheduler_actions` - `wp_actionscheduler_claims` - `wp_actionscheduler_groups` - `wp_actionscheduler_logs` Here are the individual table definitions: ```sql CREATE TABLE wp_actionscheduler_actions ( action_id bigint(20) unsigned NOT NULL auto_increment, hook varchar(191) NOT NULL, status varchar(20) NOT NULL, scheduled_date_gmt datetime NOT NULL default '0000-00-00 00:00:00', scheduled_date_local datetime NOT NULL default '0000-00-00 00:00:00', args varchar(191), schedule longtext, group_id bigint(20) unsigned NOT NULL default '0', attempts int(11) NOT NULL default '0', last_attempt_gmt datetime NOT NULL default '0000-00-00 00:00:00', last_attempt_local datetime NOT NULL default '0000-00-00 00:00:00', claim_id bigint(20) unsigned NOT NULL default '0', extended_args varchar(8000) DEFAULT NULL, PRIMARY KEY (action_id), KEY hook (hook(191)), KEY status (status), KEY scheduled_date_gmt (scheduled_date_gmt), KEY args (args(191)), KEY group_id (group_id), KEY last_attempt_gmt (last_attempt_gmt), KEY claim_id (claim_id), KEY `claim_id_status_scheduled_date_gmt` (`claim_id`, `status`, `scheduled_date_gmt`) ) ``` ```sql CREATE TABLE wp_actionscheduler_claims ( claim_id bigint(20) unsigned NOT NULL auto_increment, date_created_gmt datetime NOT NULL default '0000-00-00 00:00:00', PRIMARY KEY (claim_id), KEY date_created_gmt (date_created_gmt) ) ``` ```sql CREATE TABLE wp_actionscheduler_groups ( group_id bigint(20) unsigned NOT NULL auto_increment, slug varchar(255) NOT NULL, PRIMARY KEY (group_id), KEY slug (slug(191)) ) ``` ```sql CREATE TABLE wp_actionscheduler_logs ( log_id bigint(20) unsigned NOT NULL auto_increment, action_id bigint(20) unsigned NOT NULL, message text NOT NULL, log_date_gmt datetime NOT NULL default '0000-00-00 00:00:00', log_date_local datetime NOT NULL default '0000-00-00 00:00:00', PRIMARY KEY (log_id), KEY action_id (action_id), KEY log_date_gmt (log_date_gmt) ) ```

Indefinitely Postpone the Migration/Continue using Post Storage

To avoid the migration and to continue using post table-based storage you could add the following code to a suitable location, such as:

`wp-content/mu-plugins/action-scheduler-customizations.php` You should absolutely test this in a staging or testing environment first of all. ```php

woocommerce / action-scheduler