[wp-trac] [WordPress Trac] #57271: Cron unschedule / reschedule event errors
WordPress Trac
noreply at wordpress.org
Wed Mar 15 00:45:42 UTC 2023
#57271: Cron unschedule / reschedule event errors
----------------------------------------+------------------------------
Reporter: domainsupport | Owner: audrasjb
Type: defect (bug) | Status: assigned
Priority: normal | Milestone: Awaiting Review
Component: Cron API | Version: 6.0
Severity: normal | Resolution:
Keywords: has-patch needs-unit-tests | Focuses:
----------------------------------------+------------------------------
Comment (by galbaras):
`update_option()` calls `wpdb::update()`, which doesn't check for errors,
but it called `wpdb::query()`, which seems to be outputting messages when
errors occur. However, it doesn't do this when the database connection is
lost, in which case, I retries, and the dies if unsuccessful.
This may be our real culprit. See
[https://core.trac.wordpress.org/browser/tags/6.1/src/wp-includes/class-
wpdb.php#L2098 here].
Also, `wpdb::check_connection()` uses `$this->reconnect_retries`, which is
set to 5 without a filter, and `sleep(1)`, also without a filter in the
sleep duration. So if the connection isn't restored in 5 seconds, it's
game over, wheras in real life, restoring the connection can take a lot
longer.
Changing these values arbitrarily could cause pages to stall for too long,
but assuming this is a rare occurrence, or, as is the case with cron,
waiting isn't an issue, this may not be such a bad idea.
In fact, checking again in 1 second, then 5 seconds, then 10 seconds, then
30 seconds, then 1 minute can help get a quick reconnection when possible,
but still a reconnection when that takes longer. It's the sort of retry
logic used in networking and other systems to increase reliability.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/57271#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list