In T407403#11297163, @Krinkle wrote:

@Michael It missed the train by a few hours, so I've proposed a backport in the interest of not delaying the PHP 8.3 upgrade by an extra week. I can find a time for it, but feel free to take it if you can. If you'd like me to roll it out, could you describe briefly how to "naturally" trigger this code path from the web?

In T407152#11296498, @Reedy wrote:

https://integration.wikimedia.org/ci/job/quibble-with-gated-extensions-selenium-php81/6977/console

How many of these are broken? :(

Tentatively removing our tags. Please add them back if this turns out to be related to us after all!

Happens manually when a server admin wants to update mentor data for a single user.

Right now, this can be triggered by going to: https://pl.wikipedia.org/wiki/Specjalna:Konfiguracja_wiki/TemplateData-FeaturedTemplates

This can now probably be closed as well. The frequency of this error has massively reduced in a way that lines up with when this change would have reached Group 2 wikis:

Based on this passing QA, I think this can be closed.

Only thing left was cleaning up unused config. That has been done. Nothing to QA here.

Let's see how this looks when it arrives in production, not sure if we could see a warning from this before that. Is there a beta wiki with GrowthExperiments enabled, but suggested edits disabled, except for beta wikidata?

I don't think there can be QA for this other than rolling it out to production, turning PHP 8.3 on again and looking at the logs. If the logs are fine and this error does not show up again, then this task can just be closed.

Yes, let's resolve this right now. QA will happen via the parent and/or via T407362.

Note: estimate is about the scaffolding mainly, with the 4th criteria about wieghted tag likely needing later adjustment.

The restart helped, we got one run that finished (and apparently there was nothing to update).

But what happens when I actually have checked the checkbox, and I do another task? Do we no longer show the card highlighted in green when a user does a task?

That's a different test in that file. It seems that sometimes it edits the wrong paragraph? 🤨

In T407403#11283386, @Tgr wrote:

In T407403#11279689, @bd808 wrote:

I think a fix might be as simple as adding json_encode on the way into the BagOStuff and json_decode on the way out. This would need to be followed by rebuilding or purging the existing cached values.

JsonSerializable is one-way - json_decode() will just return a PHP array with no indication of what object is being represented. UserImpact has a newFromJsonArray() method, but something would have to call it.

Also in general JSON does not round-trip as it can't differentiate between PHP arrays and stdClass objects.

This is just a very technical sub-task that adds for now unused capabilities. The main thing is that it unblocks T405953: Apply changes to graduation mentorship settings automatically upon save. Let's resolve this task here, and then we can move forward with reviewing the change attached to that task in a future sprint.

The error seems to have stopped occurring after we bumped the cache version:

@Edtadros No, all changes have been merged into master. So the way to test these is to create a new patch-demo without any changes:

This is just a technical sub-task, there is nothing to QA here. QA will happen in a task that actually shows the onboarding, probably T407362: Finish ReviseTone onboarding quiz functionality.

For recommendation.link/__DELETE_GROUPING__: that was the legacy, partially broken way how GrowthExperiments used to deleted weighted tags under some circumstances. The code that used to do that was removed in December 2024 in context of T379522 in Remove legacy way of clearing link recommendations + temp config. So all that remains should be cleaning up these tags from the search index.

A long while back, we made the decision to get the backlog of tasks not from rejected Tone Checks in VE, but actively generated by the ML Team. So this task can be declined as the information that was supposed to be gathered in here is no longer relevant to us.

In T407192#11271072, @Urbanecm_WMF wrote:

Re tagging GitLab: We can self-service this, given we're all Owners of the repository. Not sure if the tagging is appropriate in that case.