Kill execution at unrecoverable database insert fails

[chriscct7]

In #32308 it was discovered when WordPress fails to insert a critical database error, it continues to try to execute afterwards, leaving the site error log with hundreds of errors as it tries to load objects and metas from the database tables that don't exist. When WordPress fails to install a critical database table, execution at that point should cease. A page should be shown explaining the table insert fails, along with a button to attempt to retry the operation. If that fails, debugging information that a hosting provider could find useful (like the raw SQL attempted and the result) should be shown.

[chriscct7]

It's more of a bug that WordPress doesn't handle this critical failure scenario better.

[dd32]

I don't think the proposal here is something we want to / should do.

In all cases where we insert data to the database, we should be looking at the return value to determine if it succeeded, and if not, to take appropriate action (ie. return WP_Error(), redirect, or wp_die()) before continuing with any processing.

In the case of #32308 it was exactly that, the failure to check the return values which was ultimately causing a failure.

[chriscct7]

Replying to dd32:

I'm don't think the proposal here is something we want to / should do.

In all cases where we insert data to the database, we should be looking at the return value to determine if it succeeded, and if not, to take appropriate action (ie. return WP_Error(), redirect, or wp_die()) before continuing with any processing.

In the case of #32308 it was exactly that, the failure to check the return values which was ultimately causing a failure.

If a failure in table insertion occurs, on a core table, that could leave sites completely unusable. Perhaps, the same way when an automatic core update rolls back files on a failed upgrade, if the database upgrades fail we could rollback the version as well. The proposal is basically any sort of improvement that doesn't leave a site owner with a "bricked" website following a database upgrade.

[dd32]

If a failure in table insertion occurs, on a core table, that could leave sites completely unusable.

Very few inserts exist which would result in that, and certainly very few in the upgrade routines. The proposal here doesn't actually add much, or any benefit to a user who ran into any such failure.

I think specific tickets should be opened of the style "If x insert fails, WordPress attempts using false as the ID here.." or "WordPress assumes query X always succeeds, however when it doesn't, it proceeds to perform Y which results in lost data".

[chriscct7]

Replying to dd32:

If a failure in table insertion occurs, on a core table, that could leave sites completely unusable.

Very few inserts exist which would result in that, and certainly very few in the upgrade routines. The proposal here doesn't actually add much, or any benefit to a user who ran into any such failure.

I think specific tickets should be opened of the style "If x insert fails, WordPress attempts using false as the ID here.." or "WordPress assumes query X always succeeds, however when it doesn't, it proceeds to perform Y which results in lost data".

Fair enough