Dat Hoang

Hi @nikov, I am a Software Engineer working on the WooCommerce and WooPayments codebases.

Thanks for raising this issue, and I agree that we should not send external HTTP requests for every page load, especially for non-critical info like incentives. Let me go into the technical details a bit deeper.

Current caching strategy

The GET https://public-api.wordpress.com/wpcom/v2/wcpay/incentives request is initiated in this get_incentives method. Before and after calling this HTTP request, the code has tried to do two types of caching:

• in-memory: to ensure that for every HTTP request to your WordPress site, there is a maximum of one GET request above).
• transient: can be either object cache such as Memcached/Redis/etc, or simply wp_options if sites do not have object cache. This ensures that the response for the GET request above will be cached for 6 hours if it’s an error, and 24-48 hours if it’s successful (status 200).

Possible causes

I have tried to replicate this issue on my testing sites, both local and a hosting site. However, I do not get the issue you mentioned here. Furthermore, looking at the Git blame, the relevant code has been in the codebase for nearly one year. Given all of these points, it’s likely that your site or hosting has some specific settings or cache that the relevant codebase is not covering well.

Next steps

We’re keen on figuring out what the cause is and iterating on the current codebase. To figure out the cause, it would be helpful for us if you could:

• Provide us the System Status Report (as mentioned above)
• Try to disable other plugins and keep only WooCommerce, and see if the issue exists
• Based on your screenshot, it seems you’re using the Query Monitor plugin, could you provide screenshots for the Transient Updates section too.

Hi, what’s your WooPayments version? And what plugins do you have in your site?

It might be a conflict issue in 6.6.0 and 6.6.1, which has been resolved in 6.6.2. See more reference here https://wordpress.org/support/topic/fatal-error-wcpaycontainerhasid/#post-17140444

We apologize for this conflict issue. It’s a conflict between WooPayments and other plugins/themes when using a common PHP package.

That said, we could be able to fix it, and release the fix in the recent 6.6.1 version.

Update: sorry everyone again, I mislead the information that 6.6.1 included the fix for this issue. This issue is still being worked on.

• This reply was modified 2 years, 4 months ago by Dat Hoang.

Hi @kcjpro, we appreciate your feedback here.

I am a software engineer for the WooPayments product. I’d like to iterate on this issue.

They disabled the Woocommerce Payments plugin which was making a loop process with event polling.

Besides what @csmcneill asked above, based on the initial assessment, it might be related to our Webhook Reliability service (feature), which was introduced over one year ago (March, 2022).

Allow me to explain a bit about this service. As you can see in my reference link, we carefully designed this feature to ensure that sites will only use this feature if our WPcom/WCPay server can not deliver webhook events to your site in the first time. It will stop when there is nothing more to fetch. Furthermore, those fetching actions are executed from Action Scheduler (embedded in Woo core), which would optimize this process. Note: I would call them “fetch” rather than “poll” as client sites just fetch them when they need, not always “poll” to send requests.

In fact, some of our largest merchants sometime also need to use this service, but we have not got this type of performance report so far due to this feature alone.

It’s not possible to tell the exact cause at the moment. However, it sounds like if this Webhook Reliability service causes the issue, the hosting can play a vital role here when interacting with our server, i.e. requests in and out from the hosting. Even if that’s the case, we’d like to learn more about that.

Anyway, they’re all our initial assessments, our implementations might not be perfect, and we strive to make WooPayments work flawlessly for everyone. If you can provide additional information for debugging, that would be great. You can safely provide your site information here https://woocommerce.com/my-account/create-a-ticket/ – at least the site address or the WCPay account ID would help.

We also created a GitHub issue to track your report: https://github.com/Automattic/woocommerce-payments/issues/6834

@gettingdownunder and @djav1985 – We’re sorry for the trouble here.

WCPay 3.8.1 has been released to fix this issue. Would you please update it and let us know the result?

If the issue is still there, some screenshots would be helpful for us.