Page MenuHomePhabricator

Remove changesDatabase legacy setting
Closed, ResolvedPublic

Description

This should for now always be the main entitysource repoDb

Event Timeline

Hi @Michael
As the current "unstaller" on camp for this week, could I ask for details to be added regarding why this task is in stalled / waiting?
What is it blocked on / waiting for?

Hi @Michael
As the current "unstaller" on camp for this week, could I ask for details to be added regarding why this task is in stalled / waiting?
What is it blocked on / waiting for?

Removing this setting in the entire stack requires removing it from the legacy parsers, which only makes sense by removing the legacy parsers as a whole.

The more work on this, the more I get the feeling that maybe this task shouldn't have been split vertically by legacy setting, but horizontally by degree of involvement of all the legacy setting being removed. Maybe I'll rewrite these subtasks later today.

Yeah, I think the relationship between tasks on Phabricator and changes on Gerrit is pretty fuzzy right now. But the important thing is, we have changes on Gerrit that achieve removals of these settings and pass in CI, so we’re getting there, one way or another. And with the last set of changes, this becomes doable as well, so I’ll pick it up.

This is kind of messed up:

  • Repo’s changesDatabase setting defaults to false.
  • We don’t configure it in mediawiki-config, so it’s false in production.
  • dispatchChanges.php takes that setting and creates a JobQueueChangeNotificationSender with it.
  • JobQueueChangeNotificationSender passes the value as the 'repo' param into the ChangeNotification jobs it creates.
  • In ChangeNotificationJob – now in client! – the 'repo' is therefore false, which would usually mean the local database.
  • However, as far as I can tell, the 'repo' parameter isn’t actually used anywhere. Which is good, because by this point it would refer to the client wiki’s database, not the repo one!

If it’s true that this 'repo' job parameter isn’t used, we should just get rid of it completely. However, we need to be careful: repo and client might be on different train versions, so repo still needs to set the job parameter for at least one train after client stops requiring it.

(Meanwhile, client’s own changesDatabase setting is never used at all.)

Change 704356 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Remove 'repo' ChangeNotificationJob parameter

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

Change 704357 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] DNM: Stop setting 'repo' ChangeNotificationJob parameter

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

I’ve tested locally that change dispatching still works with both of the above changes.

Change 704356 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Remove 'repo' ChangeNotificationJob parameter

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

Stalled until the above change has been rolled out to all wikis and we’re fairly confident it’ll stay deployed, so probably until 2021-07-26 or so.

Change 708074 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Remove changesDatabase setting

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

Change 704357 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Stop setting 'repo' ChangeNotificationJob parameter

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

Change 708074 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Remove changesDatabase setting

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