You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Deletion currently runs on an entirely per-post basis and isn't aware of anything else. If it scans a remote thread page and observes that a post seen there other than its target post is in it check queue, it can optimise by marking that post as not deleted which prevents it from checking that thread page another time. But that only happens coincidentally, and it can't select posts to check from the database to optimise how often that case happens.
By tracking thread page for each post, the posts that are selected to check for deletion can be optimised to minimise the number of unique pages that will be checked. This will enable the above optimisation to have as much impact as possible; additionally, it will be able to guarantee that a post not seen in that thread page was actually deleted (which the optimisation doesn't account for, needing to check for that post individually every time).
However, thread page isn't immutable. If a post earlier in the thread is deleted, posts after it in the thread move up a slot; there are 12 slots per page so necessarily 1/12 of the remaining top-level posts will change page number. After #85 we do not track posts that are not notifiable so this deletion will most likely be missed on our end. The consequence of that will be that every time an untracked post is deleted, 1/12 of the tracked top-level posts in that thread would be erroneously marked as deleted on our end.
What's the solution for that?
The text was updated successfully, but these errors were encountered:
Deletion currently runs on an entirely per-post basis and isn't aware of anything else. If it scans a remote thread page and observes that a post seen there other than its target post is in it check queue, it can optimise by marking that post as not deleted which prevents it from checking that thread page another time. But that only happens coincidentally, and it can't select posts to check from the database to optimise how often that case happens.
By tracking thread page for each post, the posts that are selected to check for deletion can be optimised to minimise the number of unique pages that will be checked. This will enable the above optimisation to have as much impact as possible; additionally, it will be able to guarantee that a post not seen in that thread page was actually deleted (which the optimisation doesn't account for, needing to check for that post individually every time).
However, thread page isn't immutable. If a post earlier in the thread is deleted, posts after it in the thread move up a slot; there are 12 slots per page so necessarily 1/12 of the remaining top-level posts will change page number. After #85 we do not track posts that are not notifiable so this deletion will most likely be missed on our end. The consequence of that will be that every time an untracked post is deleted, 1/12 of the tracked top-level posts in that thread would be erroneously marked as deleted on our end.
What's the solution for that?
The text was updated successfully, but these errors were encountered: