David..

I did try this. Disabled everything via support and the issue was still present. I am not asked for a display name.

I tried disabling the OAuth you mentioned, and the issue is still present. Are you able to reproduce on test environments perhaps?

If someone visits x website and tries to create a social login account via the Oauth connected to the community, the account creation flow is interrupted and it does not ask for display name, rather just asks to allow the scopes and redirects back to the website. This in turn seems to cause incomplete members which will eventually be deleted by the system. When creating a new account via /oauth/authorize/ URL, the account creation flow should still ask for our display name/email. This does not happen when using social logins under "Sign In Faster".

Can we schedule a 1 hour timeframe to do this? Undoing modifications and disabling plugins will basically force me to keep the community offline. So when that is done, and clearincompletemembers task is still causing issues, I can notify IPS support that the issue is still present and a review would begin shortly after.

Would IPS be satisfied enough to review the issue if: I turn off Oauth completely (turning it off completely is the fastest solution given the current information) I convert that single MyISAM table to InnoDB (ipb__core_store at 12MB) I resolve any other issues appearing under the support page And still clearincompletemembers task would cause these slowdowns? Would doing the above be enough for IPS to review the issue?

That is not likely something that can be solved within a few hours or days in this case. It is not a viable solution given the current slowdowns. Is there a way to disable clearincompletemembers task while we work on resolving the issue(s) you mentioned?

I understand. But I don't think it is related. That Oauth issue has also been there through the years and only generates one log per minute currently. Based on this, I don't see how this would cause clearincompletemembers task to cause this big of a slowdown on the entire community.

Only 1 single empty table is not InnoDB. My backup was complaining about that so I had to switch. Those seem to be Oauth issues, which should be unrelated to clearincompletemembers task, I believe. As for Cloudflare, that should not be an issue. We’ve been using it for years and we know what not to enable in Cloudflare for IPS to function.

@Jim M I can confirm now that the slowdowns are being caused by clearincompletemembers task. Are you able to look into solving this matter please?

Another issue that may be related is that the clearincompletemembers task is constantly locking for me and failing to process or complete. Could that be related to the above query/issue? I think it may be. As soon as I manually run the task, the query seems to pop up and cause a slowdown. Any way to resolve this?

@Jim M So as you saw, the community is quite snappy. The issue here is that as soon as this query comes up in the MySQL processlist, the whole community starts to slow down. IPS\Content\Search\Mysql\_Index::removeClassFromSearchIndex:279 The issue here is that the query never seems to go away once it comes up (or it does and just keeps looping? I noticed the number changes from 279 to 278 to 265 randomly). But it always is there, running. To solve this issue, a simple MySQL restart does it, until the query comes back eventually. I've never had this issue before. It only started once I attempted to use Elastic Search which did not work well for me so I switched back. Another thing that may be contributing is the recent switch to a new server, but would it be related if a simple restart and clearing of processes fix it?

I'll investigate this again and get back to you.

It’s happening again now and I notice in processlist the query is present. I won’t restart until you’ve reviewed, if you have time.

Should that be causing such a massive slowdown to the entire community then? For now, I will keep monitoring for when the issue returns and reply to this topic informing you. Hopefully you would be able to check as soon as possible as the slowdowns are quite infuriating for everyone.

Shouldn't the rebuild process take care of these? Are there after-tasks that need to be done once the rebuild is done? As mentioned above, the issue seems to go away after restarting MySQL. But it eventually comes back and that is the problem.

It has not been solved. I rebuilt both ES & MySQL search and for some reason the queries in the above screenshot keep coming back. Can someone take a look into this?

I left it running for a few more hours and it seems to have been completed now as there’s no tasks in ACP. However, there are 0 improvements or changes to search results as compared to searching while it was still rebuilding. It’s still really bad for me. Switching back to MySQL now and hopefully no issues.

After rebuilding forever, at the 80% mark I am now receiving a PHP memory exhaustion message. Is 512M not enough? Something feels wrong here. My access details are up to date.

It is the second time it comes back. But it does resolve after a restart so far. I'll do what you recommend and get back to you.

Will do. Waiting on a reply from IPS to decide as I don't want to make matters worse.

Does the posts table contain topic titles? So to resolve this would be to rebuild for ES and wait for it to complete. Then the issue should be theoretically fixed then I can decide on whether to stay with ES or switch back to MySQL?

I understand. The rebuild took quite a while and everything completed except for posts. Topic titles are most important in our case, and when searching using ES, status updates appeared way too many times - sometimes even above actual topics. This was not the case with MySQL search. Right now, nothing is processing in ACP. MySQL search is working, but it seems like there may be an underlying issue from switching to ES and back to MySQL which may need reviewing. Especially since a simple SQL restart solves the issue and clears out the process list.

I tried moving from MySQL search to Elastic Search and midway I noticed that Elastic Search results were pretty bad, so during the rebuilding of posts, I moved back to MySQL search as the results are much better. Everything was fine, but now I noticed the forum loading very slowly and checking processlist shows me this: If I reboot my database, the slow loading times are instantly fixed. So this leads me to believe that the issue is in the screenshot above. Could any staff please review and hopefully fix? I have my access information up to date

This is a thing? This definitely needs fixing ASAP.

I received this email today. What am I supposed to do? Hello, Full enforcement of the European regulatory requirement Strong Customer Authentication (SCA) started on 14 March, 2022 in the UK. This is your final notice from us to update your Stripe integration to avoid declined payments. Now that the SCA deadline has passed, two-factor authentication for online payments in the UK is fully enforced and, because your WalkingWater Account account is not SCA ready, we estimate that you could lose £18.27 in revenue over the next 4 weeks. We strongly recommend updating your Stripe integration to avoid having further declined payments. Stripe’s payments APIs and SCA-ready products are available from the Dashboard and our docs, and will help you make the required changes to your integration. Please visit our support site for answers to common SCA questions and to get in touch with us. Thanks, The Stripe team