This is not related to caching, SearchTaskSuggester::filter() should remove these results and that's called on result sets read from cache. Either the filtering logic is broken or (more likely, per T289854) search index invalidation, which the filtering is based on, is broken.

We might want to refresh the cache nevertheless, it's nice to keep the cache fresh. I think it comes down to a design choice - how much do we want to keep the task list stable? (Ie. do we think the user would prefer or find less confusing if, after doing a task and returning to the home page, they'd see the same results they saw before picking the task?) From that POV, I think this is a good change - previously we relied on randomizing the 200 cached results to pretend a random selection, but with only 20 results cached that doesn't work so well, so rotating them more often would be good.

In T290315#7331733, @Tgr wrote:

We might want to refresh the cache nevertheless, it's nice to keep the cache fresh. I think it comes down to a design choice - how much do we want to keep the task list stable? (Ie. do we think the user would prefer or find less confusing if, after doing a task and returning to the home page, they'd see the same results they saw before picking the task?) From that POV, I think this is a good change - previously we relied on randomizing the 200 cached results to pretend a random selection, but with only 20 results cached that doesn't work so well, so rotating them more often would be good.

Yeah, I'm not sure. I believe @RHo wanted to explore having a stable and non-randomized task queue per user; I think we discussed that in another phab task early on in the Add-Link project.

In T290315#7344467, @kostajh wrote:

In T290315#7331733, @Tgr wrote:

We might want to refresh the cache nevertheless, it's nice to keep the cache fresh. I think it comes down to a design choice - how much do we want to keep the task list stable? (Ie. do we think the user would prefer or find less confusing if, after doing a task and returning to the home page, they'd see the same results they saw before picking the task?) From that POV, I think this is a good change - previously we relied on randomizing the 200 cached results to pretend a random selection, but with only 20 results cached that doesn't work so well, so rotating them more often would be good.

Yeah, I'm not sure. I believe @RHo wanted to explore having a stable and non-randomized task queue per user; I think we discussed that in another phab task early on in the Add-Link project.

Hiya, yes the task is T279025. Should the tasks be merged together for discussion and/or is there a separate bug per @Tgr's comment T290315#7331733 that should be fixed separately?

In T290315#7355958, @RHo wrote:

In T290315#7344467, @kostajh wrote:

In T290315#7331733, @Tgr wrote:

We might want to refresh the cache nevertheless, it's nice to keep the cache fresh. I think it comes down to a design choice - how much do we want to keep the task list stable? (Ie. do we think the user would prefer or find less confusing if, after doing a task and returning to the home page, they'd see the same results they saw before picking the task?) From that POV, I think this is a good change - previously we relied on randomizing the 200 cached results to pretend a random selection, but with only 20 results cached that doesn't work so well, so rotating them more often would be good.

Yeah, I'm not sure. I believe @RHo wanted to explore having a stable and non-randomized task queue per user; I think we discussed that in another phab task early on in the Add-Link project.

Hiya, yes the task is T279025. Should the tasks be merged together for discussion and/or is there a separate bug per @Tgr's comment T290315#7331733 that should be fixed separately?

Thanks for digging that out. I think we can discuss the stable task queue on T279025 -- even if we implement that, this is a separate issue about ensuring that the user doesn't see invalid tasks in the task queue.

This is not related to caching, SearchTaskSuggester::filter() should remove these results and that's called on result sets read from cache. Either the filtering logic is broken or (more likely, per T289854) search index invalidation, which the filtering is based on, is broken.

I don't know if T289854: Consider removing link recommendation from search index in PageSaveComplete hook instead of SearchDataForIndex means something is broken, just that the job queue processing isn't instantaneous. Per T289854#7341932 maybe we need some kind of cache to keep track of tasks before they're removed from the search index.

Change 722593 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] Filter out invalid link recommendation tasks

https://gerrit.wikimedia.org/r/722593

Change 725764 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] SuggestedEdits: Introduce InvalidTaskTracker

https://gerrit.wikimedia.org/r/725764

Change 725764 abandoned by Kosta Harlan:

[mediawiki/extensions/GrowthExperiments@master] [WIP] SuggestedEdits: Introduce TemporarilyHiddenFilter

Reason:

I can't reproduce the issue I saw earlier that was covered by this and not by the LinkRecommendationFilter, so abandoning for now, and maybe will bring it back of the LinkRecommendationFilter doesn't suffice.

https://gerrit.wikimedia.org/r/725764

Change 722593 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Filter out invalid link recommendation tasks

https://gerrit.wikimedia.org/r/722593

On betalabs there are quite few tasks that are stuck in the SE feed. Even if I open them and click on "Back to suggested edits", the tasks don't get removed (e.g. "Technology+Add a suggested image" filters). I guess it's a specifically betalabs problems with testing data set. Otherwise, normal tasks that were accepted/rejected get filtered out from the feed.

Moving to Test in Production.

In T290315#7528341, @Etonkovidova wrote:

On betalabs there are quite few tasks that are stuck in the SE feed. Even if I open them and click on "Back to suggested edits", the tasks don't get removed (e.g. "Technology+Add a suggested image" filters). I guess it's a specifically betalabs problems with testing data set. Otherwise, normal tasks that were accepted/rejected get filtered out from the feed.

Moving to Test in Production.

They will only be removed from your feed if you accept/reject (and for rejection, the reasons of "undecided" or "foreign language" will not remove from your feed). AFAIK, there is not a business rule that says to remove the task from the feed if the user taps on it.

In T290315#7529367, @kostajh wrote:

In T290315#7528341, @Etonkovidova wrote:

On betalabs there are quite few tasks that are stuck in the SE feed. Even if I open them and click on "Back to suggested edits", the tasks don't get removed (e.g. "Technology+Add a suggested image" filters). I guess it's a specifically betalabs problems with testing data set. Otherwise, normal tasks that were accepted/rejected get filtered out from the feed.

Moving to Test in Production.

They will only be removed from your feed if you accept/reject (and for rejection, the reasons of "undecided" or "foreign language" will not remove from your feed). AFAIK, there is not a business rule that says to remove the task from the feed if the user taps on it.

Ahhh I think this may be an oversight/miscommunication about the rejection reasons, but my expectation is that for the rejection reasons where it is not removed from the pool (covered in T290046), it is still no longer shown in the specific person's tasks but remain available for others. Perhaps something for @MMiller_WMF to clarify?

@RHo one fairly simple thing to do (@Tgr proposed this in T290315#7331733) is to refresh the user's task feed after accept or reject action. Should we do that? That would take care of the problem, I think.

In T290315#7529772, @kostajh wrote:

@RHo one fairly simple thing to do (@Tgr proposed this in T290315#7331733) is to refresh the user's task feed after accept or reject action. Should we do that? That would take care of the problem, I think.

Thanks @kostajh , yes that would be good because at the moment seeing it again would be pretty confusing.

In T290315#7529775, @RHo wrote:

In T290315#7529772, @kostajh wrote:

@RHo one fairly simple thing to do (@Tgr proposed this in T290315#7331733) is to refresh the user's task feed after accept or reject action. Should we do that? That would take care of the problem, I think.

Thanks @kostajh , yes that would be good because at the moment seeing it again would be pretty confusing.

Sorry, I just realized this task is about link recommendations and not image recommendations.

For link recommendations, once you've done an accept/reject action, the link recommendation is invalidated for everyone and you shouldn't see it again in your feed.

For image recommendations, I'll follow up in T295410: [betalabs] Add image - suggested articles are not removed from Add image SE feed

We now have a specific task for per-user queue removal: T296491: Add an image: Investigate removing tasks from a user's queue after they have rejected them