Page MenuHomePhabricator

Special:EditGrowthConfig makes unrelated edits
Closed, ResolvedPublic

Description

I just did an edit to the GrowthExperiments config on enwiki. This caused not only the edit I intended to make, but also an unrelated edit to be made and attributed to me.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Hi @Pppery! Unfortunately, this happens each time Growth makes a change to Special:EditGrowthConfig and adds new fields to it. On the next edit via Special:EditGrowthConfig, those changes are reflected in MediaWiki:GrowthExperimentsConfig.json and/or MediaWiki:NewcomerTasks.json. We're thinking about how to handle that better as part of Community configuration 2.0, but I don't think we can solve it easily in the current version, unfortunately.

KStoller-WMF subscribed.

Discussed with Growth team engineers, it sounds like this issue should be resolved in Community configuration 2.0 so I'll move this to triaged for now.

Etonkovidova subscribed.

Checked for Special:CommunityConfiguration - it seems like it's another case of dirty diffs.

Testing steps:

  • tested on ruwiki beta - Special:CommunityConfiguration had there only default installation without any edits. View history for Special:CommunityConfiguration/GrowthSuggestedEdits was a fresh page with only one record made by the Maintenance script.
  • as an Admin, I added Mavetuna (as the only edit) in the field Destination page for learning more about copy editing. Clicked Save changes.
  • View HIstoroy shows:

https://ru.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki%3AGrowthExperimentsSuggestedEdits.json&diff=2579&oldid=2574

Screen Shot 2024-07-18 at 10.37.06 AM.png (1×2 px, 442 KB)
Screen Shot 2024-07-18 at 10.38.03 AM.png (1×2 px, 353 KB)

Screen Shot 2024-07-18 at 10.51.02 AM.png (1×2 px, 441 KB)

Notes from discussion:

  • This should generally be solved by the schema migration work we've done
  • There might be some historical differences that will cause this issue though
  • We could run a script to make a blank edit to catch most remaining issues. (Task to be created by Martin).
  • There are some fields that might still be an issue
  • It would be very difficult to solve this in 100% of cases, but we can certainly reduce the number of "fantom edits" by making sure we update the files when we make a change to the software (reflecting what we do in code on wiki).
  • This task will help: T365145: Community configuration: Support nullable types
Etonkovidova claimed this task.
  • We could run a script to make a blank edit to catch most remaining issues. (Task to be created by Martin).

Done as T371678: Allow sysadmins to make an empty edit to a configuration provider.

Re-checked in beta - the diffs seems to be good - they show only edits that are actually done by admins