Opened 10 years ago
Closed 10 years ago
#32352 closed defect (bug) (invalid)
Kill execution at unrecoverable database insert fails
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Database | Keywords: | |
Focuses: | Cc: |
Description
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.
Change History (7)
#2
@
10 years ago
- Keywords early added
- Priority changed from normal to high
- Type changed from enhancement to defect (bug)
#4
follow-up:
↓ 5
@
10 years ago
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.
#5
in reply to:
↑ 4
@
10 years ago
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, orwp_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.
#6
follow-up:
↓ 7
@
10 years ago
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".
#7
in reply to:
↑ 6
@
10 years ago
- Keywords dev-feedback needs-patch early removed
- Milestone Awaiting Review deleted
- Priority changed from high to normal
- Resolution set to invalid
- Severity changed from major to normal
- Status changed from new to closed
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
It's more of a bug that WordPress doesn't handle this critical failure scenario better.