This should be all ready for code review. Once patches uploaded here get merged, using CC should be the default. There will be few other tests to follow-up on:

Considering we're nearing the end of the sprint, I decided to scope out some of the unstarted work to followup tasks. I filled:

@Sgs I moved back to Doing, as the Gerrit patch caused some CI errors. I reviewed & merged the GitLab PR, which is OK. Let me know if there is anything else I need to review here!

In T380329#10347078, @Etonkovidova wrote:

Thx, @Urbanecm_WMF! Quite an investigation, very impressive.
Checked azwiki (the number of excluded sections is 21. The api call for link recommendation for HP-GL article (where the issue was reported) doesn't return any recommendations anymore.

@KStoller-WMF asked me to review the difficultness here. This task should be a configuration change of the wgGECampaigns (changing the pattern from /^typage-\w+-\w+-2023$/ to /^typage-\w+-\w+-\d+$/). That should be possible to do at any time.

In T380329#10342547, @Urbanecm_WMF wrote:

In T380329#10342542, @Urbanecm_WMF wrote:

I'll revalidateLinkRecommendations.php for azwiki now, so that this new list is enforced.

Started:

[urbanecm@deploy2002 ~]$ mwscript-k8s -- extensions/GrowthExperiments/maintenance/revalidateLinkRecommendations.php --wiki=azwiki --all --verbose                                                                                                   
⏳ Starting extensions/GrowthExperiments/maintenance/revalidateLinkRecommendations.php on Kubernetes as job mw-script.codfw.22qey0zx ...                                                                                                            
🚀 Job is running. For streaming logs, run:                                                                                                                                                                                                         
K8S_CLUSTER=codfw KUBECONFIG=/etc/kubernetes/mw-script-codfw.config kubectl logs -f job/mw-script.codfw.22qey0zx mediawiki-22qey0zx-app                                                                                                             
[urbanecm@deploy2002 ~]$

The underlying problem appears to be in CentralAuth (T380500); I added it as a subtask.

Filled T380455: Run revalidateLinkRecommendations.php for wikis with more than 25 excluded sections for the revalidateLinkRecommendations.php execution, to ensure task pool actually follows the configuration. Other than that, this can probably be resolved.

In T380329#10342567, @Urbanecm_WMF wrote:

In T380329#10342562, @KStoller-WMF wrote:

Based on the comment, "Cap the limit of sections-to-exclude somewhat arbitrarily at 25," I assume this was a best-guess at a technical limit

It indeed seems so. However, I currently do not understand what the technical reason for introducing it was (is it just a safeguard preventing someone from excluding thousands of sections? or does each excluded section mean recommendations take significantly longer to produce? something else?).

Could we increase that limit to 100, and ask Kosta to review the patch in case he has more insight into the original limit? Or, I'm fine removing the limit, but if the list grows too large might we end up encountering other issues related to performance?

Unfortunately, I don't know. I'll need to better understand what the limit protects us from. Then, I should be able to answer this question. I'll check with Kosta, but he might not remember either, given this was done years ago.

I'm working on this anyway, and now that it is rootcaused, finishing the rest should be straightforward.

In T380329#10342562, @KStoller-WMF wrote:

Interesting! You really are the best Phabricator sleuth!

In T380329#10342542, @Urbanecm_WMF wrote:

I'll revalidateLinkRecommendations.php for azwiki now, so that this new list is enforced.

In T380329#10342526, @Nemoralis wrote:

OK, I removed unnecessary 14 section names from that list.

I spot checked how many excluded sections exist at other wikis:

In T380329#10342507, @Urbanecm_WMF wrote:

TLDR: The Add Link service restricts the number of excluded sections to 25. [...] First and foremost, we should figure out why was this limit introduced.

TLDR: The Add Link service restricts the number of excluded sections to 25. When this limit is exceeded, the API does not provide any indication the request was incorrect – it merely ignores the 26th (and following) excluded sections. Since azwiki has 35 excluded sections, it results in this bug.

Follow-up to prioritized work (T379682, T380271).

One thing I'm not following is why are user properties called here in the first place. In T380271, the traceback goes from ResourceLoaderEntryPoint, which disables accesses to getUser() and the like (code has to be user-agnostic). In user-agnostic code, there shouldn't be a need for user preferences in the first place?

Fair point. Let's degrade the severity to debug, and we can raise it back to error once we figured things out.

I disagree with labelling this as a train blocker. Logs added in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1091303 do not _cause_ the errorneous behaviour, they only make it more visible. We're working on the underlying problem, and since this is not a new issue introduced by wmf.4 ("just" increased visibility), I think removing logs from the dashboard temporarily makes sense here.

In T380161#10333962, @Urbanecm_WMF wrote:

Add Link (structured) and Add Link (legacy) should now be deployed to 50% users each at test.wikipedia.org. Let me know if anything does not work as intended/expected.

Add Link (structured) and Add Link (legacy) should now be deployed to 50% users each at test.wikipedia.org. Let me know if anything does not work as intended/expected.

Should now be ready for testing.

Deployed, testing via parent.

A great deal of the PHPUnit failures is this:

According to today's standup, I will focus at PHPUnit failures, and @Michael will take a look at the browser test failures.