Doing the others now:

• arcwiki
• arwiki
• azwiki
• bgwiki
• cawiki
• commonswiki
• cswiki
• dawiki
• dewiki
• dewikiversity
• dewikivoyage
• enwiki
• enwikibooks
• enwikiquote
• eswiki
• eswiktionary
• etwiki
• fawiki
• fiwiki
• frwiki
• frwikisource
• hrwiki
• huwiki
• idwiki
• itwiki
• itwikivoyage
• jawiki
• kowiki
• kvwiki
• metawiki
• nlwiki
• nlwiktionary
• nowiki
• oswiki
• plwiki
• ptwiki
• ruwiki
• ruwiktionary
• slwiki
• sourceswiki
• srwiki
• svwiki
• tawiki
• testwiki
• trwiki
• ukwiki
• zhwiki

In T222848#5252939, @Cntlsn wrote:

In the two no-Js scenarios above I would only consider displaying the message if browsing to another page and then back to the homepage would remove the message.
Would that be the case?

The script finished on dewiktionary, and fixed all the rows with missing ar_sha1 values. I've undeleted the remaining revision on Böotien, and this bug should no longer affect undeletions on dewiktionary. I'll run the script for the other wikis tomorrow.

The testwiki run failed to remedy any of the 11 missing ar_sha1 entries because those archive rows point to broken text rows, with the external store URL DB://cluster20/0. I suspect this is the story behind most of the wikis that only have a handful of missing SHA1s. It's now running for dewikivoyage and that does seem to be doing something.

In T219816#5251887, @Catrope wrote:

The populateRevisionSha1.php maintenance script includes code that finds rows with a blank ar_sha1 and populates them, but there's currently no way to run only that step without also recomputing the SHA1 for every single revision and archive row in the entire database. I'll write a patch so that we can do this next week (this week is a no-deploys week).

In T225848#5260048, @ssastry wrote:

Tangential to the actual bug report, given that mw:Param is only inserted for top-level {{{..}}} that can't be expanded and hence is emitted as is, not sure why Parsoid html2wt insists on data-mw for this case.

In T225318#5256845, @Cntlsn wrote:

• the banners we show to no-Js users won't be auto-dismissible with a timer, and won't be dismissed by user interaction. I guess it should still be possible to use either the query string approach or the user preference to only show the banners to no-Js users once (only after account creation), but wanted to double-check that.

Yes, that's right.

In T224076#5211547, @MaxSem wrote:

I'm good with Apache or MIT.

In T225668#5254814, @MMiller_WMF wrote:

@Catrope @SBisson @Etonkovidova -- are these browser versions we're supposed to support? If so, we will want to address it for the MVP release. If not, then this will not need to be addressed.

It works fine for me on Android too:

In T225318#5243473, @MMiller_WMF wrote:

@Catrope told me that the sitenotice option is actually feasible. @Catrope, could you fill us in on your recommendations for these users?

Not all types of site notices work in no-JS, because some of them are based on stuff like geo location. However, if all our links/redirects that lead from the account creation / welcome survey flow to wherever users end up next add a query string parameter (say, ?showhomepagetour=1), then we could see that query string parameter on the server side and output a site notice into the HTML. No-JS users will then see that site notice. For JS users, that site notice HTML will also be delivered, and we can either let it stand, or hide it with CSS and instead show a GuidedTour (or display both).

Strangely, I can't reproduce this locally, even in a Vagrant setup with CentralAuth. Perhaps it's specific to having the master and replica be different servers.

I think this happened because the change made DatabaseMysqlBase::doSelectDomain() use executeQuery() whereas it previously used doQuery(). The former has the assertIsWritableMaster() check but the latter bypasses it. USE queries appear to be considered write queries (because they're not explicitly marked as read queries by the regex in Database::isWriteQuery()), so this failure started happening every time we try to switch databases in MySQL.

I believe https://gerrit.wikimedia.org/r/c/mediawiki/core/+/512043 is likely to be the culprit.

The first error of this type appeared at 20:05:59 UTC today (June 12)

I was going to take a look but can't because of T225682: Login, account creation, anything else that accesses global user throws DBReadOnlyRoleError in beta labs, so I'm going to investigate that first.

There are 1043 Logstash events in the last 30 days that match +exception.trace:"RecentChangeSaveHookHandler" and only 9 of them match +exception.trace:"RecentChangeSaveHookHandler". However, the other 1034 all have the same stack trace, which is the one from T225200: Fatal error during CirrusSearch-LinksUpdate job (CirrusTitleJob) from JobQueueGroup->push. (I checked that all of the non-ORES events match +exception.trace:"requeueError".) So they probably have the same root cause (or similar root causes).

The preference is labeled "Show Wikidata edits *by default* in recent changes". If you don't have it enabled, the default state of the RC filters when you open RC will be such that Wikidata edits aren't shown, but if you then change the filters they may end up being shown. I'm not sure how we could make this clearer.

Some of the deleted revisions for this page have ar_sha1 set to an empty string, which is what causes this error. For this page, this only affects the revisions dated November 2012 and earlier. The ones after November 2012 do have ar_sha1 set, and I was able to undelete those successfully.

On stat1006:

(for wiki in $(cat ~/all.dblist); do echo -n "$wiki: "; echo "select count(*) from archive where ar_sha1='';" | analytics-mysql $wiki -N; done) | tee ~/empty-sha1
cat ~/empty-sha1 | grep -v ': 0'

In T222848#5237747, @Cntlsn wrote:

Thanks @kostajh and @Catrope for your feedback on this!

I also agree that redirecting the users to the Homepage would be the best option for the user experience.
Just want to make sure I understand correctly how this would work: after clicking on the link in the email, the Special:ConfirmEmail page will load and after some time it will redirect to Special:Homepage?
Or actually the redirect to Special:Homepage would be so quick that the user won't be able to see the Special:ConfirmEmail page?
The reason I'm asking is that if we're in the first scenario, then I think it would be good to offer some kind of feedback of what's happening to the user, like a message with indication that the user is being redirected and a countdown, or something similar.

Note that one of the reasons we put the name and the date in the header was to help make the header (more likely to be) unique, because with duplicate headers it's a pain to link to the right one. But that's only true for wikitext talk pages, not in Flow where every topic has an internal ID that's used for links. That's not to say that having dozens of topics on the same page all named "Help panel question" wouldn't still be confusing/annoying, so that might still be a valid reason to keep the username, or the date, or both.

The code from CentralNotice that does this: https://github.com/wikimedia/mediawiki-extensions-CentralNotice/blob/master/includes/CentralNoticeHooks.php#L230-L240

OK, if we can get away with not TTLing the data at all, that would certainly be simpler!

In T222014#5210597, @Anomie wrote:

Note that making internal calls like that is a "code smell", though. I started trying to abstract the business logic of it from the API "front-end" in gerrit:460436, but priorities and team assignments changed and I haven't had time to work on it for a while.

In T215983#5235259, @MMiller_WMF wrote:

• If the user's total edit count is less than or equal to 1,000, then display the article edit count with this language: "4 edits to articles"
• If the user's total edit count is greater than 1,000, then display the total edit count with this language: "1,123 total edits"

I've submitted a patch on top of Stephane's that does this: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/514412

More than one day, probably close to a week. This also requires a combination of doing some thinking about how exactly to approach this, and getting a brain dump from Piotr.

I like Kosta's idea of showing a "your email is verified" message based on whether the user was redirected from Special:ConfirmEmail to the home page.

In T224473#5232490, @Etonkovidova wrote:

Moving the task back to Incoming as the case needs more discussion.

Looking into history - I did not see reverted or any indication of the content being removed in some point.

In T215983#5233425, @SBisson wrote:

MediaWiki Core maintains a per-user total edit count that we can display. It turns out counting the edits for a single namespace is too expensive. We can change it to show the total edit count for all namespaces or, as Roan suggested in the patch, count up to 50 and then display 50+.

Yes, the user will lose their unsaved edit if they navigate to Special:ChangeEmail. Clicking the link would first show them a warning that they're about to lose unsaved content, and they have to click through that to leave the editor and go to Special:ChangeEmail. After they finish changing/setting their email address, they will see a link taking them back to the page they were on (because of returnto, as Marshall said), which will also open the editor again (because of returntoquery, which will be set to action=edit or something similar). I believe VisualEditor will recover the unsaved change in this case, but despite that I think that making the user navigate away during an edit session is bad and we should avoid it.

In T185664#4778396, @Jrbranaa wrote:

@Catrope, we can certainly find another home for this extension if you think another team is a better fit. Out of curiosity, is this related at all to the change from Collaboration to Growth? I'm trying to get a sense of whether the wrong call was made when we first reviewed this extension for Code Stewardship or if things just changed since then.

Thanks for cleaning this up, @Krinkle and @thcipriani. I heard about this problem during the hackathon, but forgot to work on it and then went on vacation. The way it was solved is exactly what I had in mind,

Yes

In T223526#5189549, @Theklan wrote:

It works (partially). It moves the link only if the "In other projects" section exists.

In T223526#5189390, @Theklan wrote:

Maybe we can do it only for Basque wikipedia using js?

This could be the same as / similar to the button in the email submodule of the account module on the home page. Technically that button is just a link, and it links to Special:ChangeEmail (not to preferences).

This also applies to the help panel, which shares (much of) the relevant code with the help and mentorship dialogs.

Sounds sane to me; except that I think the scope might need to be extended to random other bits (beyond namespaces, log types and i18n) that we're not thinking of now but will discover when we try to undeploy an extension.

The "sitenotice" area mentioned in option B is where the Wiki Loves Earth banner is in the screenshot below. If no banner is shown, the sitenotice area is empty (so not easy to point out in a screenshot), but it still exists and we can put stuff in it.

We have three main options:

• A: Put something in the "chrome" area of the page (the upside-down-L-shaped area along the top and left edge of the screen), which includes the sidebar, personal links and tabs along the top
• B: Put something in the "sitenotice" area, which is where site notices, central notices and fundraising banners go
• C: Put something in the content area of the main page

In T222851#5170947, @EvanProdromou wrote:

@Catrope also, I talked to @kaldari by email yesterday, and he thought that all the data was going into the main stash. Is that true? I might need to review the Echo code again.

Migrating from one storage backend to another, and from individual keys to pairs, would be a bit complicated. @mobrovac suggested that it would be easier if we could do both of these migrations at the same time. One way to do that would be to create a config setting that takes an array of storage backends, and have the code try these in order when reading. That way we can configure it to read first from the new backend, then the old backend (and then the user preference, which we still have fallback code for today), but only write new values to the first one, and we could make the pair vs separate keys thing a property of each storage backend as well.

I ran the script above to recompute the notification counts for every user who could potentially have been affected by this (users who had at least one unread login-success notification). It took a while to run, but it finished some time yesterday. This should completely resolve the issue: new cases shouldn't happen (unless someone changes a notification type from being available on web to unavailable on web again), and existing cases should now be fixed. Nobody should be seeing wrong counts or phantom notifications anymore.

Wrong bug, sorry. Neither of these patches addresses this bug, although 508488 is semi-related.

As I was talking this through with @Krinkle on IRC, he pointed out that in WMF production, we only run rebuildLocalisationCache.php once, on the deployment server, and then distribute the CDB files it generates to the application servers(*). rebuildLocalisationCache.php doesn't run on each app server. Together with $wgLocalisationCacheConf['manualRecache'] = true, this means that LocalisationCache::recache() only runs once, on the deployment server, many seconds (even minutes) before any of the app servers have the new CDB files. Reverting 7f1a3bc742 will cause MessageBlobStore::clear() to be called at this time, but that's not very useful. The MBS cache will be invalidated, but then it'll just be repopulated with stale data.

Since the reason that clearing the MessageBlobStore from LocalisationCache was originally disabled is now moot (MBS isn't DB-based anymore), and since MessageBlobStore::clear() is just a touchCheckKey() call nowadays, I think we can safely revert rOMWC7f1a3bc742ed: Disable MessageBlobStore::clear() via hook. I will upload a patch to do that now.

It turns out MessageBlobStore's normal update mechanism for when messages change was disabled in the WMF config by rOMWC7f1a3bc742ed: Disable MessageBlobStore::clear() via hook, because of T29320: MessageBlobStore::clear() causes scaling problems on multi-server setups with CDB l10ncache. However, that bug might be moot since MessageBlobStore no longer uses the database. I think this probably broke when we stopped running LocalisationUpdate, because the only thing that appears to run refreshMessageBlobs.php (referenced in the comment in that config patch) is l10nupdate-1, which I don't believe we run anymore.

For some reason, this particular message has failed to update on every wiki that it's been deployed to. I'll force-update it in about half an hour, and will investigate why this happened after.