aetta
Forum Replies Created
-
Hi @rithikmeta ! thanks for the update and the new release. We tested after the change and saw clear improvements on performance, but a few regressions in reliability. Details:
What improved
- Per-action runtime: Completed
chain_batchactions now finish very fast .. avg ~1.20s, p95 ~2s (measured Oct 21–28). This is a big win compared to our earlier ~40s average and occasional multi-minute outliers. - Bursting: The top bursts dropped to ~22–27 actions/min (previously we observed 30–50/min). This has helped overall CPU stability.
What got worse
- Failure rate: Post-release we saw an increase in failed
chain_batchactions:- Oct 20–23: ~1.3–1.7% failed/day
- Oct 24–28: ~2.7–3.3% failed/day
- Failure pattern: Most failed actions show only “action created” (sometimes “started via Async Request”) and then “action marked as failed after 300 seconds,” with no intermediate logs. That looks like a runner timeout rather than an application error.
Volume
- Daily volume remains high (1.2k+
chain_batchactions per day), but given the shorter runtimes and reduced bursts, total load is more manageable.
We’re running real system cron (async runner disabled), no CDN/WAF in front, and investigating server-side timeouts/worker availability to understand why some actions never progress before the 300s mark.
We’re also checking whether failures correlate with specific batch numbers (args look like
[batch_no, []]) or times of day; so far, the failures appear evenly distributed.That said, I’d ask if:
- Is there any additional logging or a filter we can enable to capture pre-timeout steps for these actions?
- If batch sizing was increased, is there a recommended queue runner time limit or batch size we should align with on large catalogs (12k+ products) to minimize these 300s timeouts?
Overall, the performance side looks much better… thank you for that. The remaining blocker is the reliability of
chain_batch(these silent 300s timeouts). Thanks a lot!Hi @rithikmeta ! Happy to hear that and excited to use it!
Thanks for getting back to me!
Cheers,Hey y’all! Any update on this?
Hey @danielbmxd , I made a post really similar to yours about a week ago and haven’t gotten any replies yet. I’m just snooping around here to see if you get any answers that could help me as well! 🙂
just to add a bit more info, after further investigation:
- Hostinger’s LVE snapshots confirm multiple
lsphp index.phpprocesses consuming 100% CPU each during these spikes, running heavy queries againstwp_posts,wp_term_relationships, andwp_postmetatables, consistent with product feed generation. - The spikes on the hosting panel at 10:00 UTC+2 time align with these bursts of promotions feed tasks.
First, thanks for all the work you’ve put into this plugin… it’s been a huge help! I dug into the code and saw you’re using both the Store API hook (
woocommerce_store_api_checkout_order_processed) and the standard checkout hook (woocommerce_checkout_order_created) in addition towoocommerce_thankyouandwoocommerce_view_order.Perhaps, firing the QR code generation so early in the checkout flow is unintentionally triggering Elementor’s conditions logic on the checkout page, which leads to that “Undefined array key ‘checkout_layout’” warning from Elementor.
I suspect if the QR code ran only after the order is complete (for example, on the thank-you or order-view pages), the warning would stop appearing without “waking up” the elementor’s conditional thing.
Perhaps just //commenting those hooks will prevent them from running too early, not sure if it will affect other instances also, but I can try it later on if this makes sense to you!
Thanks againHey @goasklecom!
Thanks for the tip about turning off Elementor experiments and tweaking the display_errors setting. I’ve already tried disabling Elementor’s experiments, but the issue persists (Im not using any of them at the moment also).
My best guess is that the plugin is calling Elementor’s Conditions API on the front end without providing a default forcheckout_layout. Hiding the warning feels like sweeping it under the rug, and I’d rather tackle the root cause. Could you take another look at how the plugin hooks into Elementor conditions and suggest a way to either supply a fallback forcheckout_layoutor limit that integration to the editor/order-received context?Really appreciate any guidance you can share. Let me know if you need logs or want me to try anything else!
it’s just a warning anyway, and I am doing a couple of cleanups, so no rush at all!Howdy! Happy to hear that! Can’t wait for this fix! Thanks a bunch, and shout if you need anything else from me.
Appreciate it!
Forum: Plugins
In reply to: [Meta for WooCommerce] Lost ConnectionHowdy folks!
@marijastuntcoders , here it is:
https://eglow.me/ffwoo.txtFantastic! Let me know if you need anything else on my end!
ThanksForum: Plugins
In reply to: [Meta for WooCommerce] Lost ConnectionHowdy @marijastuntcoders !
I am on behalf of @abbasrizk, and here are the logs requested:Let me know if you need anything else! I’ll be happy to help!
Best,Hey there! Thanks for the fast reply!
This seems to happen occasionally and in batches. What I’ve identified is that sometimes the product doesn’t have a featured image or the review doesn’t have an attached image (perhaps related to the product?).In any case, it appears the plugin is always assuming it will receive an array of URL/image, and when it doesn’t, it gets
falseand$image_urlbecomes a boolean.
Forcing the use of an image placeholder may solve the issue too (but this isn’t something I can do at the moment)
ThanksI thought I had already answered this, but it worked like a charm! Thanks for the quick response and fix!
Howdy folks! I did a quick/dirty fix until your awesome team work on it. cc @priyankajagtap
Just to add a bit of context, the problem was that the default invoice template does not list variation details such as color, size etc. To fix it, I hooked intowcdn_order_item_afterto detect variable products, gather all meta keys that start withattribute_and then output each one as a list item below the product name.
I just added this as a code snippet so I can quickly deactive when you fix it officially!add_action( 'wcdn_order_item_after', 'show_variation_attributes_after_item', 10, 3 );
function show_variation_attributes_after_item( $product, $order, $item ) {
if ( ! $product || 'variation' !== $product->get_type() ) {
return;
}
$variation_data = [];
foreach ( $item->get_meta_data() as $meta ) {
if ( 0 === strpos( $meta->key, 'attribute_' ) ) {
$variation_data[ $meta->key ] = $meta->value;
}
}
if ( empty( $variation_data ) ) {
$variation_data = $product->get_variation_attributes();
}
if ( empty( $variation_data ) ) {
return;
}
echo '<ul style="margin:4px 0 0;padding:0;list-style:none;">';
foreach ( $variation_data as $attr_key => $attr_value ) {
$taxonomy = strpos( $attr_key, 'attribute_' ) === 0
? str_replace( 'attribute_', '', $attr_key )
: $attr_key;
$label = wc_attribute_label( $taxonomy, $product );
if ( taxonomy_exists( $taxonomy ) ) {
$term = get_term_by( 'slug', $attr_value, $taxonomy );
$value = $term ? $term->name : $attr_value;
} else {
$value = $attr_value;
}
echo '<li style="font-size:0.85em;color:#555;">'
. esc_html( $label ) . ': ' . esc_html( $value )
. '</li>';
}
echo '</ul>';
}I hope this helps, if any of you folks are going to try it, I’d suggest applying in an staging env first and use it as a snippet, so you can also quickly disable it when they fix it!
Forum: Plugins
In reply to: [Ultimate Responsive Image Slider] PHP Fatal error after WordPress 6.8 updateAwesome folks! Appreciate the quick fix on this! Kudos to y’all!
Thanks - Per-action runtime: Completed