Yan Knudtskov

Hi @scottklaviyo

Thank you for you reply, we wen digging a bit futher and found the cause of the issue seemed to be an underlying bug in WooCommerce Subscription where subscriptions that were cancelled got called again and again with order updates.

We were able to locate the Stack Trace of it through this method:

add_action('woocommerce_update_order', 'yanco_woocommerce_update_order', 10, 1);
function yanco_woocommerce_update_order($order_id)
{
    $wc_logger = wc_get_logger();
    $trace = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 20);
    $formatted_trace = '';
    foreach ($trace as $i => $frame) {
        $file = isset($frame['file']) ? $frame['file'] : '';
        $line = isset($frame['line']) ? $frame['line'] : '';
        $function = isset($frame['function']) ? $frame['function'] : '';
        $class = isset($frame['class']) ? $frame['class'] : '';
        $formatted_trace .= "#$i $file($line): $class$function()\n";
    }

    $wc_logger->debug(
        "Order #$order_id updated",
        array(
            'stack' => $formatted_trace,
            'source' => 'order_update_debug',
            'order_id' => $order_id,
            'action' => 'woocommerce_update_order',
        )
    );
}

This should not be left running for a long time as it can log quite a bunch of data on a system that has a lot of subscriptions on it 😅

Hi Zubair Zahid (woo-hc)

This started at Sep 2nd at 17:09 according to our log files.

Disable Express Checkout does resolve the issue, but as the client needs to use ApplePay that is not an option or a way to solve the issue.

As outlined in my quite thorough description, I’ve narrowed down the issue for you, so there’s no doubt at all the problem comes from the ApplePay part of the plugin.

From reviewing the codebase of Stripe for WooCommerce, the entire issue stems from this:

includes/class-wc-stripe-apple-pay-registration.php, line 47

add_action( 'admin_init', [ $this, 'verify_domain_on_domain_name_change' ] );

This hook would will call:

/**
 * Trigger Apple Pay registration upon domain name change.
 *
 * @since 4.9.0
 */
public function verify_domain_on_domain_name_change() {
	if ( $this->domain_name !== $this->get_option( 'apple_pay_verified_domain' ) ) {
		$this->verify_domain_if_configured();
	}
}

Which then calls (note the flush_rewrite_rules() call in the function):

/**
 * Process the Apple Pay domain verification if proper settings are configured.
 *
 * @since 4.5.4
 * @version 4.9.0
 */
public function verify_domain_if_configured() {
	$secret_key = $this->get_secret_key();

	if ( ! $this->is_enabled() || empty( $secret_key ) ) {
		return;
	}

	if ( ! $this->is_available() ) {
		return;
	}

	// Ensure that domain association file will be served.
	flush_rewrite_rules();

	// The rewrite rule method doesn't work if permalinks are set to Plain.
	// Create/update domain association file by copying it from the plugin folder as a fallback.
	$this->update_domain_association_file();

	// Register the domain with Apple Pay.
	$verification_complete = $this->register_domain_with_apple( $secret_key );

	// Show/hide notes if necessary.
	WC_Stripe_Inbox_Notes::notify_on_apple_pay_domain_verification( $verification_complete );
}

Hooking into admin_init seems to be a very unsure way to go, as that would potentially cause the flush_rewrite_rules() every time the /wp-admin/ is initialized – For a site with 10s of thousands of visitors and a very active /wp-admin/ order handling, that can easily drown a system.

The right way to go about it would be to setup a WP-CRON scheduled task or using the Action Scheduler to do this check on a regular basis – it really should not be hooked I believe.

Please relay that to the developers 😊

It works 😀 Brilliant! thank you 🙂