Page MenuHomePhabricator

wgEchoEnablePush config is brittle
Open, Needs TriagePublic

Description

Push notification support is only enabled on wikis in the wikipedia group at present. This is accomplished using the EchoEnablePush config setting provided by the Echo extension.

A few wikis had to be individually excluded yesterday to resolve a train blocker (T291128). This solution is brittle because the problem could reappear anytime a new private wiki is added to the wikipedia group. This task is to implement a more future-proof solution.

Potential solutions:

  1. Create the push tables in private wiki DBs, and enable the push notifier type universally. This would have the added benefit of allowing the push notifier type to be defined and configured in Echo like the web and email types rather than being special-cased in CommonSettings.php. The drawback is that this could potentially cause the users of the Wikipedia apps to receive notifications for wikis irrelevant to them, but this could be handled by the app clients (either by appropriate use of per-wiki filtering when requesting notification content, or post-hoc filtering of received notifications).
  2. Investigate options for updating configuration to be more future-proof, e.g., to exclude non-SUL wikis by group. (Would $wgEchoEnablePush = [ 'default' => false, 'wikipedia' => true, 'special' => false ] have the desired effect? Note that arrays in PHP are actually ordered maps, so if MediaWiki applies these rules in the order defined, it should work.)
  3. Create the echo_push_* tables in the local DBs of all non-SUL wikis, even if there are no immediate plans to use them.

Event Timeline

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

@Etonkovidova Who would you recommend discuss this?

Also, farewell @Mholloway ! Thanks for the parting ticket. :-D

@Etonkovidova Who would you recommend discuss this?

Growth team devs should evaluate the ticket for prioritization.

Also, farewell @Mholloway ! Thanks for the parting ticket. :-D

Yes, thak @Mholloway! And such a nice ticket number :)

Thanks @Etonkovidova . I'm gonna tag @kostajh and @DMburugu to make sure it gets to the right dev eyes, as needed. :)

thank you for summarizing @Mholloway!

@Marostegui would you be OK with option 3? I'm not sure how time consuming that is for the DBAs, but it is less work than option 1, and less error prone than option 2.

thank you for summarizing @Mholloway!

@Marostegui would you be OK with option 3? I'm not sure how time consuming that is for the DBAs, but it is less work than option 1, and less error prone than option 2.

Table creation is self-service, done by the deployers ;-). We should define conditions for wikis that should have the local table, so when new wiki gets created, it will be respected.

Another option would be to investigate why are arbcom wikis in wikipedia.dblist and remove if no reason is found -- more time consuming than just creating tables, but the most beneficial, as it will help others who have a Wikipedia-only feature :-).

A relatively simple option should be to explicitly disable push notifications in CommonSettings.php, if CentralAuth is not enabled. This should avoid the need for any new tables, and I think it is most error prone approach (considering both current and future wikis). We already do something similar for things like GlobalUserPage extension, so it is not a new thing either.

Another option would be to investigate why are arbcom wikis in wikipedia.dblist and remove if no reason is found

I'll take the opportunity to link the task about this that you mentioned the other day: T183549: Arbcom wikis are in both wikipedia.dblist and special.dblist

thank you for summarizing @Mholloway!

@Marostegui would you be OK with option 3? I'm not sure how time consuming that is for the DBAs, but it is less work than option 1, and less error prone than option 2.

Not sure I get the meaning of option 3.
Does that mean not using x1 like the rest of echo_* tables?

As @Urbanecm mentions, table creation are self service. But if they need some sort of filtering (to avoid replicating to clouddb hosts), they do need to wait for us to put the filters in place.
If the tables would go to x1, then no filters would be needed as we exclude x1 entirely.

Creating tables are self-service but I suggest a double check of the schema with data persistence team or someone with good knowledge of databases. (With some info on growth plan, etc.)

My only worry (not seeing the schema) is s3, adding a new table to each wiki might add 1k more tables and I remember we had issues with that in the past (that's why we moved some wikis from s3 to s5).

[...]
My only worry (not seeing the schema) is s3, adding a new table to each wiki might add 1k more tables and I remember we had issues with that in the past (that's why we moved some wikis from s3 to s5).

Note the tables are in x1, not alongside the wiki's main tables. There's only one x1 section, and to me, it makes little difference to create the tables at 8 more wikis (non-CA wikis that are in wikipedia.dblist), when we already have them at ~300 wikis. I may be wrong in that, of course :-).

Thanks @Urbanecm it wasn't clear if they'd go to x1 or to the sX sections itself - hence my question at T291200#7364425

[...]
My only worry (not seeing the schema) is s3, adding a new table to each wiki might add 1k more tables and I remember we had issues with that in the past (that's why we moved some wikis from s3 to s5).

Note the tables are in x1, not alongside the wiki's main tables. There's only one x1 section, and to me, it makes little difference to create the tables at 8 more wikis (non-CA wikis that are in wikipedia.dblist), when we already have them at ~300 wikis. I may be wrong in that, of course :-).

oh it's only for these eight wikis? It's good to go on my side then!