Active member

This is a pretty serious bug. If a user with the ability to move posts moves one out of a large thread, it is likely going to be a little slow. There is no feedback that it is working on it to the end-user, and they may try to hit move again. The post will end up moved, but all posts in the entire thread are hard deleted and have to be recovered from a backup.

We have a thread that currently has 26,000 posts. One post was moved to another thread in another forum. However, the person doing the move hit the move button multiple times, due to the move being slow, and no feedback that it was being performed. It also didn't prevent them from repeatedly attempting to move the post. Eventually the single post moved, but all 26,000 posts and the thread were hard deleted, and we had to restore the thread from the previous night's backup.

Member

Not sure if this situation was considered given that this single thread is larger than many/most entire boards out there but hopefully a solution/fix can be come up with because it won't be the only time this happens for us. With ~50 staff and approaching 30 million posts it is bound to happen again.

The MultiPrefix code just allows the target thread to have multiple prefixes by tweaking the preSave in the target thread.

SV/MysqlReplication routes provable non-transactions read-only queries to slaves.
SV_SlowQueryLogger_Profiler just records if the query takes longer than ~10 seconds, and doesn't interfere with the code flow.
(And patched the error class to report the hostname of the box which generated the error).

I restored the thread* into SB's testing environment but I'm able to safely move posts out of that 26000 post thread. I'm planning to rebuild the testing environment off live in the next day or so, and then will re-import the thread.

*Script used to generate an SQL dump from an old backup is attached. This generates a ~100mb SQL file for that thread

Well-known member

Well-known member

SV_SlowQueryLogger_Profiler just records if the query takes longer than ~10 seconds, and doesn't interfere with the code flow.
(And patched the error class to report the hostname of the box which generated the error).