[wp-trac] [WordPress Trac] #33463: Flooded 'wp_batch_split_terms' in cron

[WordPress Trac]

#33463: Flooded 'wp_batch_split_terms' in cron
--------------------------+------------------------
 Reporter:  array064      |       Owner:
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  General       |     Version:  4.3
 Severity:  normal        |  Resolution:  duplicate
 Keywords:                |     Focuses:
--------------------------+------------------------

Comment (by boonebgorges):

 Replying to [comment:6 leedo]:
 > Replying to [comment:5 boonebgorges]:
 > > Duplicate of #33423.
 > >
 > > @Kent Brockman - Check out [33646], and in particular, the
 `upgrade_431()` routine. If you can't wait until 4.3.1, you can run a
 similar routine yourself (eg in an mu-plugin).
 > We managed to end up with 150k of these cron events scheduled before
 rolling back to 4.2.4. I'm not sure if that is worse than expected, our
 setup is multisite and gets quite a bit of traffic. Running the code to
 unschedule the tasks in upgrade_431() takes prohibitively long with such a
 large list. I think there is probably a more efficient way, directly
 updating the entire option at once. Maybe most sites won't have 150k items
 to remove, but if they do, it will take much longer than can be run in a
 single HTTP request.

 Yes, see the updated commits on #33423, which switch it to a single
 `update_option()` rather than a `foreach` loop. Also, note that this issue
 is not a symptom to trying to split all shared terms in a single HTTP
 request - WP tries to do it in batches. The issue in this ticket and
 #33423 is that in certain edge cases, the initial term-splitting cron job
 is not set during the normal 4.3 update routine.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33463#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform