Bug #10633
closedTribe__Meta__Chunker->is_supported_post_type runaway queries
0%
Description
Two times in the last three days I've gotten emails from my long-running-request tool that indicate some sort of problem related to the combination of the BPGES asynchronous emailing routine and the Tribe Events Calendar plugin. The queries look like this:
[15] => Array
(
[0] => SELECT * FROM wp_1165_posts WHERE ID = 51110 LIMIT 1
[1] => 0.0021059513092041
[2] => do_action('wp_ajax_wp_bpges_send_queue'), WP_Hook->do_action, WP_Hook->apply_filters, WP_Async_Request->maybe_handle, BPGES_Async_Request_Send_Queue->handle, BPGES_Async_Request_Send_Queue->handle_immediate_queue, bpges_generate_notification, ass_send_email, bp_send_email, do_action_ref_array, WP_Hook->do_action, WP_Hook->apply_filters, BuddyPress->{closure}, BP_Email->get, apply_filters('bp_email_get_property'), WP_Hook->apply_filters, bp_core_deprecated_email_filters, BP_Email->get, apply_filters('bp_email_get_tokens'), WP_Hook->apply_filters, bp_email_set_default_tokens, get_post_meta, get_metadata, apply_filters('get_post_metadata'), WP_Hook->apply_filters, Tribe__Meta__Chunker->filter_get_metadata, Tribe__Meta__Chunker->applies, Tribe__Meta__Chunker->is_supported_post_type, get_post, WP_Post::get_instance
)
and there are hundreds of them - by my reckoning, one for each email sent in a batch.
The problem here appears to be that:
a. The BPGES routine is being triggered from a secondary site
b. When BP fetches the email object, it's not switching to the root blog to do it, so WP_Post::get_instance() request is returning null
c. Neither the Tribe tools, nor WordPress, nor the object cache, are smart enough to bail out of querying over and over again
I'm going to investigate to see whether this needs to be fixed in BPGES (ie by ensuring we're switched to the main blog for at least part of each send-batch; though this will be problematic because it could change the "From" address etc) and/or in BP (the API should always be looking for email objects on the root blog).
Related issues
Updated by Boone Gorges about 6 years ago
- Related to Bug #10605: cac-onboarding email sending routine can cause near-infinite db requests added
Updated by Boone Gorges about 6 years ago
I think that this specific issue could be at least mitigated by BuddyPress. I've opened https://buddypress.trac.wordpress.org/ticket/7996#ticket to discuss it. As a workaround, we can do the blog-switching ourselves. Maybe something like:
add_filter( 'bp_email_get_tokens', function( $tokens ) {
if ( ! bp_is_root_blog() ) {
switch_to_blog( bp_get_root_blog_id() );
add_filter( 'bp_email_get_tokens', function( $tokens ) {
restore_current_blog();
return $tokens;
}, 9999 );
}
$return $tokens;
}, 0 );
I think it's likely that this is only one part of the overall problem. The issue here feels very close to #10605, but that other bug presumably wouldn't be addressed by the `switch_to_blog()` trick.
Ray, could I ask for your feedback on this, please?
Updated by Raymond Hoh about 6 years ago
- Related to Bug #6710: GES resulting in infinite loop added
Updated by Raymond Hoh about 6 years ago
- Related to deleted (Bug #6710: GES resulting in infinite loop)
Updated by Raymond Hoh about 6 years ago
The issue here feels very close to #10605, but that other bug presumably wouldn't be addressed by the `switch_to_blog()` trick.
I think the options you laid out in the BuddyPress ticket are spot on. There isn't enough switch_to_blog() calls happening at the moment since the existing switch calls are only used to grab the BP email in bp_get_email(). If the BP_Email class methods like get() are used like in the BP deprecated email filter, it needs another switch call there.
The workaround that you posted would only work for email tokens. Is there a likelihood that other email properties would be affected by this switch bug? The debug log appears to show that the bug only affects email tokens, so we should be safe to just do the switch for tokens only, but something to think about.
One other workaround to consider is to remove all hooks to 'get_post_metadata' during the BP email send or BPGES email send routine. It is highly unlikely that a plugin will need to access the post meta for a BP email post object.
Updated by Boone Gorges about 6 years ago
- Status changed from New to Duplicate
Thanks, Ray! I lean in the direction of a broader fix than just addressing the email tokens. I think we ought to switch_to_blog() for the whole of bp_send_email(). But I want to get Paul's thoughts about that before moving forward with it.
One other workaround to consider is to remove all hooks to 'get_post_metadata' during the BP email send or BPGES email send routine. It is highly unlikely that a plugin will need to access the post meta for a BP email post object.
Something like that had occurred to me too. But it seems too specific to our problem, not really addressing the broader issue; and there could, after all, be a legitimate reason to filter metadata in these situations.
In any case, I think that the disabling of deprecated code in https://redmine.gc.cuny.edu/issues/10605#note-4 will fix the immediate problem here. The broader problem in BP can be addressed on BP Trac.