In T248405#5995875, @egardner wrote:

@Catrope This is not urgent, but it would be nice to have a resource module for Vuex in core that works similar to the one for Vue itself. Right now I'm including the Vuex code in a vendor subfolder but other projects will presumably need to use this soon as well.

This also happened on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/583339 . @Reedy investigated this briefly, but was confused because there's a specific exclusion for this directory in the phan config

This is still broken, and was causing confusion during the 4pm SWAT deployment. Thankfully scap appears to route around broken proxies, so it didn't fail to sync 1/9th of the Apaches as I feared it would.

This happened because rEGREb5316d1d36cd: Help panel: Add root screen buttons (for T244546: Newcomer tasks: guidance root screen) made significant changes to HelpPanelProcessDialog, without realizing that QuestionPosterDialog is a subclass of it. In other words, the mentorship dialog (and the other "ask a question" dialogs) are implemented as some modifications on top of the help panel, so changing the structure of the help panel broke them.

Returning this task back to the pool because I don't understand the search backend well enough, I'll need @Tgr to help me or tell me what to do here.

I tried to do this by randomizing the order in which the task types are sent to the API, because the API appears to return results ordered exactly the same as the task type list it receives. However, that only works if no topic filter is set. With a topic filter, this order isn't respected, and in fact there seems to be no rhyme or reason to the results ordering as far as I can tell (neither in terms of task type nor topic).

In T241180#5923538, @EvanYou wrote:

4. For the v3 migration, this is the currently planned procedures:
   1. v2.7 will be released with deprecation warnings for features that are set for removal. This release will also become an LTS version with 18 months of extended support time.
   2. v3 will come with a "compatibility build" that exposes v2 behavior (where applicable) via feature flags and provide deprecation warnings / migration guidance when v2 usage is detected. v2 compat feature flags that can be turned off individually so the migration can be performed piecemeal.
   3. Codemods will be provided for simple API syntax changes that can be automatically upgraded.
   4. A migration helper will scan the codebase and provide guidance for any changes that cannot be covered by the compatibility build or codemods (we try our best to avoid such changes, but sometimes they are inevitable).

Hope this addresses the stability concerns.

The main part of this (the new UI for ORES topics) is now in code review. Next, I'm going to work on separating the topic preferences for morelike vs ORES, so that when we switch to ORES, everyone's topic selections will be blank and they'll see a blue dot (per a conversation with @MMiller_WMF). After that, I'll work on the design tweaks that the task description asked for.

Closing this since the MABot issue is resolved; I've filed T246398: Echo does not recompute notification counts when notification subscriptions are changed through a global preference for the underlying issue.

In the database, I do see 1 unread notification each for MABot on eswiktionary and euwikibooks. They're both "thank you for your 100th edit" notifications. The one on eswiktionary is from July 2019, and the one on euwikibooks is from April 2019. However, MABot has disabled thank-you-edit notifications using global preferences. I think this is probably the source of the bug: saving one's global preferences only causes notification counts to be recomputed on the wiki where you did that, not globally (and generally, hooks listening for preference changes won't be fired when the preference change happens through global preferences).

This broke MW-Vagrant, which uses PHP version PHP 7.2.16-1+0~20190307202415.17+stretch~1.gbpa7be82+wmf1

In T245499#5914449, @dbarratt wrote:

@Catrope wow thank you for all of that! :)

In T245499#5914125, @Catrope wrote:

dropping the ORDER BY, which can significantly speed up the query in some cases.

Do you think the LIMIT on the main subquery is worth the cost of the ORDER BY on the subquery?

Yes. In my pathological example (which I realize is pathological, but still), adding a LIMIT reduced the query run time from 29 seconds to ~2 seconds. You are right though that the ORDER BY does make the query slower sometimes, it's just that in extreme cases the un-limited-ness makes it slower still.

I played around some more, and decided to throw the worst at it that I could come up with. With a user with ~300k rows, an IP address with ~300k rows, and an IP range with ~800k rows (so 1.4M rows scanned in total), the query from the task description took 29 seconds. Adding LIMIT 100000 (that's 100k) to each of those subqueries took it down to 8 seconds. Adding a timestamp condition (>= 1 Feb, so 23 days' worth of data) made it 5 seconds, and then setting the limit to 33,333 (so that the limits add up to 100k) got it down to 2 seconds. That seems pretty acceptable. The worst-performing part seems to be IP range scans that return lots of results, because then MySQL is stuck between a rock (using the cuc_timestamp index for sorting, then a manual where for the IP range) and a hard place (using the cuc_ip_hex_time index for the IP range, then a filesort for ordering by timestamp).

Ooh, this subquery materialization stuff is really helpful, thanks! I knew that using the indexes to get rows by user/IP should be possible, but I didn't know how to tell MySQL to do it. Adding an index to help the GROUP BY will likely improve performance too.

I ranted about a few gaps in our current Message interface, specifically the (lack of) interaction between RawMessage and MessageLocalizer, here: T227233#5305488.

In T228746#5897245, @Anomie wrote:

In T245573 @Catrope suggested another potential way to fix this: cleaning up the string inside LuaSandbox after it comes from Lua, in luasandbox_timer_profiler_hook() and luasandbox_push_structured_trace().

In T164307#5907530, @subins2000 wrote:

I have one doubt : Does the current edit model have a field to identify whether the edit is a revert ? Or does that need to be implemented ? From reading this, I understand that only a method needs to be implemented to know it, and that the model already has a field to know what is the edit type (revert or not) ?

The DBQueryError was: Error: 1062 Duplicate entry '\x05\xC1Ue\x09\xC1\xD8\xD2\xC2\x10U' for key 'flow_revision_unique_parent' (10.64.32.11)

In T245073#5878817, @Jdforrester-WMF wrote:

Need to backport?

I broke this a year ago in rMW1c7c9bdf1fc5: Use packageFiles feature to replace special-purpose RL modules, apparently nobody noticed.

This is a regression from rMW6786aa5d8e2e: Support pagination on multiple columns in the IndexPager, caused by the fact that ImageHistoryPseudoPager completely reimplements doQuery(), including code that lives in IndexPager::extractResultInfo(), which was modified in an incompatible way.

But the topics themselves should be displayed alphabetically in the local language. Engineers, please let us know if that doesn't look like a good approach.

This shouldn't be an issue.,

In T241180#5828334, @Jhernandez wrote:

In T241180#5827364, @egardner wrote:

There will be some limitations to this approach:

1. we'll rely on Vue's built-in template compiler for the time being, which means shipping a little bit of additional code in production;

This is irresponsible. For the amount of traffic we have, the amount of extra computation we are going to force on millions of clients because of our inability to get our process together.

I don't think that that would help. I was measuring mtime deltas not because I think there's a bug of the type you're alluding to, but as a proxy for finding out whether the bad servers generated their cache files very shortly after the scap happened. If the cache file is only a tenth of a second younger than the settings file, that might indicate some sort of race condition, but at 0.25 seconds that's less plausible, and at 3 seconds it's definitely not plausible.

It happened again today, with this patch. This time I left it broken for a while so I could investigate.

Thanks to Giuseppe I got dsh+keyholder to work: SSH_AUTH_SOCK=/run/keyholder/proxy.sock dsh -r ssh -F 20 -M -g mediawiki-installation -o -i/etc/keyholder.d/mwdeploy -o -oUser=mwdeploy -o -oBatchMode=yes -- 'echo "echo \$wgGEHomepageSuggestedEditsTopicsRequiresOptIn ? \"BAD\" : \"good\";" | sudo -u www-data php /srv/mediawiki/multiversion/MWScript.php eval.php --wiki=cswiki | head -n 1'

I encountered this bug again today, when deploying this config change. My teammates reported that the feature we'd just enabled was working about half the time, which likely means that about half (or at least a significant fraction, much more than 10%) of the app servers had an outdated config, I tried to use dsh to count how many app servers were affected, but I couldn't get keyholder to work. It gave me a "Too many authentication failures" error message for each host.

It looks like @kaldari has updated the wiki page: https://www.mediawiki.org/w/index.php?title=Requests_for_comment%2FURL_shortener&type=revision&diff=3618236&oldid=2842533

Supplementing this with the reasoning that Amir provided in his commit messages, and highlighting what the changes are:

In T242052#5813863, @MMiller_WMF wrote:

@Tgr -- okay, I just talked to @Catrope about wanting to SWAT this on Tuesday. Because we don't want there to be a few days of the topic era that don't have this element as part of their events.

The config patches are done. The next step is for @Trizek-WMF to set a deployment date for each wiki.

The config patches are done. The next step is for @Trizek-WMF to set a deployment date for each wiki.

Which namespace(s) and/or categories the Help panel search should handle = https://hy.wikipedia.org/wiki/%D4%BF%D5%A1%D5%BF%D5%A5%D5%A3%D5%B8%D6%80%D5%AB%D5%A1:%D5%8E%D5%AB%D6%84%D5%AB%D5%BA%D5%A5%D5%A4%D5%AB%D5%A1:%D5%95%D5%A3%D5%B6%D5%B8%D6%82%D5%A9%D5%B5%D5%B8%D6%82%D5%B6

@Trizek-WMF: We don't support category search here yet, you can only search in entire namespaces. Right now, all wikis that have the help panel search in namespaces 4 (Wikipedia) and 12 (Help).

Which namespace(s) and/or categories the Help panel search should handle (0 is mandatory) = 0, 4; Kategória:Segítség

I don't believe 0 is mandatory here at all. The normal setting is 4, 12 (Wikipedia and Help). We also don't have support for searching in categories right now.

On which namespaces it have to be deployed = 0, 2, 4

Shouldn't this be 2, 4, 12? That's how all our existing wikis are configured. Including 0 worries me in particular. See also T231720#5811842

The ukwiki and huwiki patch don't enable the help panel in the main namespace in read mode, even though that was requested, because it's unusual and we've never done it before. If we decide that is desired, we can do it, but for now I'm erring on the side of caution. I brought this up on the Ukranian-specific task at T231720#5811842.

On which namespaces it have to be deployed = 0, 2, 4

Just checking, this means the help panel would appear in read mode on pages in the main, User and Wikipedia namespaces, but not in the Help namespace. Is that intended? On every other wiki that has the help panel, we don't enable it in the main namespace, and do enable it in the Help namespace (in other words, we do 2, 4, 12). Note that this is just about where the help panel appears in read mode; in edit mode it will appear in every namespace.

The patch above is incomplete, we'll need to add the URLs of the translated privacy policies once they're available. Assigning to @MMiller_WMF since he's the liaison with Legal for that.

This is ready to go, waiting on a decision from @MMiller_WMF as to when to deploy this. We probably want @nettrom_WMF to be around?

I can't reproduce this on desktop Chrome (with or without mobile emulator), desktop Firefox (with or without mobile emulator), or mobile Chrome (on Android). Does this only happen on iPhones? Does it happen in desktop Safari too?

For completeness: if you want to turn topic matching back off and test the UI that normal users see, you can run step 3 but with the 1 changed to a 0:

new mw.Api().saveOption('growthexperiments-homepage-suggestededits-topics-enabled', 0).done( function() { window.location.reload() });

Looks good to me

In T241180#5801407, @Jdrewniak wrote:

I'm very excited about this proposal and eager to adopt a modern framework like Vue!
I think there's still a lot of infrastructure that needs to be put in place to take advantage of single-file components, and I'm wondering what the developer experience is like without them.

Supporting single-file components wouldn't actually be that hard at all. With small modifications to our existing infrastructure, we could have ResourceLoader automatically remap SFCs to JS component definitions (with the template as a string), because this transformation is very simple. We wouldn't be able to support ES6 or scoped styles though (because those depend on preprocessing steps that use nodejs libraries).

In T242400#5803375, @Dyolf77_WMF wrote:

I created the page and made the changes as suggested.

In T223988#5775582, @Hmxhmx wrote:

@Catrope Would that PR also solve the same problem with dates in Special:Notifications?

I've scheduled the config patch for the 19:00 UTC SWAT on Thursday Jan 16. The train should already have run by then (it's scheduled for 14:00-15:00 UTC).

Once this is deployed, the following console snippet will enable topic matching in production:

new mw.Api().saveOption('growthexperiments-homepage-suggestededits-topics-enabled', 1).done( function() { window.location.reload() });

To turn it back off, change the 1 to 0.

I think having the branch be cut at a fixed time would be good in general, because it would make the process more predictable. It would be helpful if the branch cut happened late enough in the day that there's an opportunity for people to merge patches on Tuesday morning in time for the train, but I also recognize that you can't both cut it late enough that developers on the US west coast have a chance to merge patches (say 18:00 UTC) and also cut it early enough that a releng team member in Europe can run the train (which currently happens at 14:00 UTC, when it happens).

There are some issues with the existing code in MachineVision that I ran into when I copied it to GrowthExperiments:

• It depends on mediawiki.template.mustache+dom, which is in the WikibaseMediaInfo extension (MachineVision already depends on WBMI, but it doesn't make sense for GrowthExperiments to depend on WBMI)
• The mustache+dom templating engine avoids destructively rerendering embedded OOUI widgets, which is good, but it does destructively rerender nodes created by the template. This is a problem, because it breaks CSS transitions for state changes.
• Because CSS transitions don't work, the widget uses CSS animations instead. But that causes a bug where the widgets animate (the text moves from left to right) when they're being unhidden or added to the DOM.
• There is no clean group widget for these, so I had to make one by picking the relevant pieces from ImageWithSuggestionsWidget (which contains a lot of other things as well). Without that, the SuggestionWidgets don't behave correctly, because they rely on a CSS class set on the parent element to hide the outline.
• These widgets don't extend SelectWidget and OptionWidget, which means you have to reinvent some wheels around selection management and getting the selected values from the group widget for example

Links to the config pages:

Like Kosta I also ran out of time, so I'll put this back in the pool so that either Kosta can pick it up in his morning, or I can pick it up in my morning tomorrow.

The button doesn't do anything yet when clicked, but I'm going to implement that as part of T238612

In T238610#5756884, @RHo wrote:

hi there - I think the mock-ups were based on the v1.0 'final mocks' which have since had minor text changes. I've just updated to match what's in the copy doc and happy to go with option B as well.

These are now done:

• Czech: https://cs.wikipedia.org/wiki/MediaWiki:NewcomerTopics.json
• Korean: https://ko.wikipedia.org/wiki/MediaWiki:NewcomerTopics.json
• Arabic: https://ar.wikipedia.org/wiki/MediaWiki:NewcomerTopics.json
• Vietnamese: https://vi.wikipedia.org/wiki/MediaWiki:NewcomerTopics.json

I have transferred the config to this page on viwiki, which is protected so that only admins can edit it: https://vi.wikipedia.org/wiki/MediaWiki:NewcomerTopics.json

In T240512#5787027, @MMiller_WMF wrote:

@kostajh @Tgr @Catrope -- when I try this on Czech or Korean Beta, I am able to select a task type from the dropdown, but the topic field remains free text, with no choices. Does something need to be changed?
I'm here: https://cs.wikipedia.beta.wmflabs.org/wiki/Speci%C3%A1ln%C3%AD:API_p%C3%ADskovi%C5%A1t%C4%9B#action=query&format=json&list=growthtasks