(Removing team tags as it is up to teams what they plan to work on.)

@RhinosF1: Unfortunately this report lacks some information. What do you expect to see? What do you see currently? Which specific criteria to apply which allow judging whether this task is done and successfully resolved at some point? Unspecific "make everything faster somehow" tasks are not helpful. :)

In T223315#5186548, @Aklapper wrote:

(Removing team tags as it is up to teams what they plan to work on.)

Copied exactly from parent task - Based on discussion there adding Platform Engineering seems appropriate

@RhinosF1: Unfortunately this report lacks some information. What do you expect to see? What do you see currently? Which specific criteria to apply which allow judging whether this task is done and successfully resolved at some point? Unspecific "make everything faster somehow" tasks are not helpful. :)

! In T222533#5168793, @MMiller_WMF wrote:

@RhinosF1 -- would you say that the larger issue is that the watchlist takes a long time to clear, or that the user doesn't have any warning that it will take a long time? The latter is obviously faster and easier to fix than the former.

! In T222533#5182114, @JTannerWMF wrote:

We will fix the message on this, however the speed is not within scope of this team. We believe the Platform Engineering would be responsible for the speed. We will use this Phab task for the message and Platform Engineering can use another for the speed.

See the above posts from the parent task that is being used to add a message alerting users temporarily while Platform Engineering improve the performance of clearing through an improved system

@RhinosF1: You seem to have posted a few comments from the other task, but no answer to my question?

In T223315#5188396, @Aklapper wrote:

@RhinosF1: You seem to have posted a few comments from the other task, but no answer to my question?

Essentially, it's per the parent task. See there but the TL;DR Is going through a job queue takes a long time and it can be rebuilt to not use that which will be quicker. The taks is resolved when as you click save the changes happen ideally. What do I see/expect is answered in the parent task.

In T223315#5188492, @RhinosF1 wrote:

What do I see/expect is answered in the parent task.

@RhinosF1: It should be summarized and answered here (in the task description) so people don't have to read through discussions in some other task, including clear objective criteria that allow defining when to call this task resolved.

In T223315#5210072, @Aklapper wrote:

In T223315#5188492, @RhinosF1 wrote:

What do I see/expect is answered in the parent task.

@RhinosF1: It should be summarized and answered here (in the task description) so people don't have to read through discussions in some other task, including clear objective criteria that allow defining when to call this task resolved.

@Aklapper : It does now - Is this comment general or aimed at this task? Ping me on IRC if you want to discuss how to format it more as it'll be quicker

Adding back into the Core Platform Team inbox so we can discuss this at our task triage meeting.

I note that the job queue clearing was added specifically because the old code that did do direct clearing was too slow. It's hard to insert/update/delete hundreds of thousands of database rows.

So, we on CPT think that it's essential to use the job queue for large watchlists, because older code that did the deletion directly would time out.

I think our tasks here are the following:

• Review if there's any obvious optimization to do in the query itself
• Review and confirm if there's any reason this job is being deprioritized (I don't think that's possible, but it's worth confirming)
• Coordinate with Growth on T222533 so we support setting/unsetting a flag for showing a message on Special:Watchlist.

I think we should probably lead on that last part; it's not useful to show the message if the flag doesn't exist.

T222533 is on #growh-team's radar, but I don't think the other optimizations are things we'd have time to do in the short-to-medium term.

@Krinkle: Is this and T41510 not same thing?

This task is about the processing of submissions, from Special:EditWatchlist/raw and Special:EditWatchlist/clear. The main problem is that, after you're shown the list and indicated what you want to change and submit it, that processing such submission is slow.

Task T41510 is about the the displaying of the checkbox-based interface at Special:EditWatchlist. The main problem there is the expensive nature of generating that many checkboxes whilst displaying the page. It is not about processing its form submission.

I hope I got that right, and if I did, that it made sense :)

In T223315#5804097, @Krinkle wrote:

This task is about the processing of submissions, from Special:EditWatchlist/raw and Special:EditWatchlist/clear. The main problem is that, after you're shown the list and indicated what you want to change and submit it, that processing such submission is slow.

Task T41510 is about the the displaying of the checkbox-based interface at Special:EditWatchlist. The main problem there is the expensive nature of generating that many checkboxes whilst displaying the page. It is not about processing its form submission.

I hope I got that right, and if I did, that it made sense :)

Yep, makes sense now

So, we on CPT think that it's essential to use the job queue for large watchlists, because older code that did the deletion directly would time out.

I also came to this conclusion while working on the refactoring around watchlists and watched items.

I came up with a possible alternative for the issue that prompted the creation of this ticket at T222533#7972289