I didn't find the one from the 17th, but I found WXQm7QpAAEQAADieuagAAAAC from the 23rd reported above:

In T171027#3480263, @Catrope wrote:

In T171027#3480259, @Kf8 wrote:

More than 15 users reported this problem in RuWiki, I personally need to reload my watchlist 2-3 times to make it work, and most of the time I get http://i.imgur.com/UUPQDVo.png
People try to delete entries from their watchlists, to limit the number of entries, to enable 'expanded watchlist', but all that is of little or no avail.

How old is that screenshot? I tried searching for that error ID (the "number" that starts with WWwB) but I didn't find anything.

In T171027#3480259, @Kf8 wrote:

More than 15 users reported this problem in RuWiki, I personally need to reload my watchlist 2-3 times to make it work, and most of the time I get http://i.imgur.com/UUPQDVo.png
People try to delete entries from their watchlists, to limit the number of entries, to enable 'expanded watchlist', but all that is of little or no avail.

Strange. https://meta.wikimedia.org/wiki/MediaWiki:Mw-widgets-usersmultiselect-placeholder/de shows the translation but https://meta.wikimedia.org/wiki/Special:Preferences?uselang=de#mw-prefsection-echo doesn't. I wonder if we're using this message in the content language or something.

This seems to just be the mw-widgets-usersmultiselect-placeholder message, am I missing something?

In T162786#3476782, @Etonkovidova wrote:

(1) @jmatazzoni

Clicking the button opens a menu that lists the following options under "Changes to show": 20, 50, 100, 250, 500

The option to show 20 changes should be added? Currently it's not added anywhere - betalabs and several wikis I checked do not have it.

In T167902#3471195, @Niharika wrote:

Some questions from the meeting:

1. Is it possible to have global blacklist instead?

A "truly" global blacklist would be tricky because it would basically require global preferences, but @Jdforrester-WMF suggests a simpler way to do it could be to make the blacklist preference only available on meta. (Or perhaps it could "live" there but be visible on all wikis with the same value, through some hackery.)

In T168487#3474933, @SBisson wrote:

From the task description:

There should be no highlighting for these rows regardless of whether it's using the original ORES highlighting or the newer highlighting done by RC Page itself.

Note that the patch above doesn't handle the original ORES highlighting.

Good point, I'll fix that.

In T162784#3473444, @Krinkle wrote:

Since you're looking at this code, might be able to give this lower priority tech-debt/bug a shot:
T149890: Fatal error on Special:Recentchanges when days=800000 or higher

In T168487#3473450, @gerritbot wrote:

Change 367841 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/ORES@master] Treat RC_LOG and RC_EXTERNAL rows as unscorable

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

In T167902#3472128, @TBolliger wrote:

I think it is important for the Mute list to be easily reachable from the Echo feature itself — the 'Preferences' link is prominent in the Echo dropdown itself and is a natural path for users to follow. There are other possibilities — including a separate special page which is transcluded into or linked to from Special:Preferences but the fewer hoops the better.

This isn't really related to cross-wiki-ness but instead to easily accessing the mute feature, right? One thing our team considered while we were working on Echo was to add a secondary action to notifications that would allow you to mute them. Our ideas at the time were about muting by topic/page/type, not by user, but the concept translates. See "Muting from the panel" in T115264#2248740 for a mockup that @Pginer-WMF made at the time.

Looking at the code, I don't see how you could ever end up in this situation. The relevant code is as follows:

/*
 * Add primary key, but only after we've made sure the newly added
 * column has been populated (otherwise they'd all be null values)
 */
if ( $updater->updateRowExists( 'FlowPopulateRefId' ) ) {
        if ( $updater->getDB()->getType() === 'sqlite' ) {
                $updater->addExtensionIndex( 'flow_wiki_ref', 'PRIMARY', "$dir/db_patches/patch-ref_id-phase2.sqlite.sql" );
        } else {
                $updater->addExtensionIndex( 'flow_wiki_ref', 'PRIMARY', "$dir/db_patches/patch-ref_id-phase2.sql" );
        }
}

So it only attempts to run patch-ref_id-phase2.sql if the updatelog table claims that FlowPopulateRefId has already run. That check has been there since the very beginning, as well (it was added at the same time as patch-ref_id-phase2.sql itself).

Does FlowPopulateRefId get run by update.php already? Maybe it's just run too late? By default, such maintenance scripts are run after all schema changes, and that appears to be harmful in this case.

In T167899#3371423, @debt wrote:

This might be better solved with the Tool-Global-user-contributions team.

Clarification: this query is looking for edits tagged visualeditor in the Talk namespace, and there aren't any. Not sure what if there's anything we can do about this, because it's hard to know in software that this is an impossible combination.

We could probably put in something in the Cite extension that adds information to the ParserOutput object about references on the page (somewhat similar to how tracking categories and the link/category arrays work), and then check that in PageTriage.

In T171544#3468370, @jmatazzoni wrote:

@Catrope, should this be in the list of blockers for beta graduation?

This will be deployed today around 23:00 UTC (a little over an hour from now).

This is working for me now; perhaps it was the same issue as T171081: Trash can button (reset to defaults) resets days and limit in model but not UI ?

Very strange. Could you please do the following:

• Install the WikimediaDebug extension (if you haven't already)
• Turn it on, point it to mwdebug1002 and check the "Log" checkbox
• Hit Special:Recentchanges (with no params)
• Open a console and dump wgRequestId
• Give me this ID (putting it in a comment on this task is fine)

The default watchlist view runs a query without a LIMIT (!!). I have a WIP patch that fixes this as part of a much larger refactor, but for the time being you could work around this problem by enabling the "enhanced watchlist" preference ("Expand watchlist to show all changes, not just the most recent"), because that mode does use a LIMIT.

The beta RecentChanges tool was recently removed

No it wasn't? What makes you say that?

Did the first two: https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=delete&page=MediaWiki%3ATog-usenewrc and https://en.wikipedia.org/w/index.php?title=MediaWiki%3AWikibase-rc-show-wikidata-pref&type=revision&diff=791704415&oldid=537782264

After reading @SBisson's patch (linked above), testing it, and hearing him talk about it, I have two questions for @Pginer-WMF and @jmatazzoni:

In T103389#3136334, @jcrespo wrote:

A large amount (much more than 30%) have 'wikitext' content model.

Then an index there will not be useful in most cases (it will not speed up the search)- the mysql optimizer will ignore the usage of such index and do a full scan instead.

Probably a regression from rGOJUe5a613ea173d: WikimediaUI theme: Variablize PopupWidget values which added margin to the footer without justifying it in the commit message.

In T170723#3456110, @Trizek-WMF wrote:

@Catrope, can you confirm the release schedule? We have said on Monday, right?

I just tested this and it worked for me: https://meta.wikimedia.org/wiki/Special:Log/notifytranslators . I deliberately chose a language that had nobody signed up to it (Extremaduran), then had @Quiddity sign up so my test would go to him and only him. Puzzlingly, the log entry says that it went to 2 recipients instead of 1 (maybe because he signed up for both talk page and email notifications?). In any case, the logging appears to be working.

To clarify: this already works when you do things like https://en.wikipedia.org/wiki/Special:Recentchanges?days=23&limit=42 , it just doesn't work when you do the same thing through your preferences.

In T150419#3457353, @TBolliger wrote:

@Catrope — I just tested the UI and the mute functionality on beta, looks good to me. I say we release it on Meta with the next release.

Sounds good to me! Of course I would say that, though, because our software only uses damaging and goodfaith :) . But I think this is a good idea generally speaking.

In T164997#3297713, @Mooeypoo wrote:

Technical question here - it seems like we need to have 2 sub-messages for what we current have as a single message (so, splitting the description for "Likely have problems" to the "low" case and "high" case) and then making sure that specific wikis (regardless of interface language used on them!) receives each specific one.

@Catrope how do we technically do this? Do we create 2 messages for translation, and then let the back-end decide which to ship based on a list of wikis? Do we need to create another sort of global-global variable (or config option?) to set apart the list of wikis per message?

Am I over-analyzing this, or do we need to create the infrastructure to do this? I was going to implement, but then got blocked on how to make sure each wiki gets the correct low/high representation.

Fair enough. User creation from the extension's init function is problematic anyway, so we should fix that.

Translation: the min-height we use on .rcfilters-container is not enough any more, now that the saved filters feature has been added. We have min-height: 100px, but the height of that element when the interface finishes loading is now 162px. This means the results list is pushed down by 62px when the interface finishes loading. We should increase the min-height to be sufficient, so that this doesn't happen.

How about @Pginer-WMF 's three-dots suggestion from T165286: Explore more subtle way to indicate filter loading status?

From the duplicate task: this is an Accessibility problem for people with equilibrium disorders, who are particularly sensitive to moving images

In T168835#3411279, @Pginer-WMF wrote:

• Figure out why the bookmark icon is even larger than the rest, and reduce it to fit with the rest of the icons.

Declining this task because as you point out, the live update feature will make this gadget unnecessary.