Change 572254 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] HTMLUsersMultiselectField: Pass through config for widget's input

Mentioned in SAL (#wikimedia-cloud) [2020-02-14T15:14:09Z] <bd808> Restarting bot to pick up config changes for T245242

Wonderful, thank you @SBisson @Aklapper @hueitan for all the informative replies. Certainly learned something from this thread, will take a look at translatewiki.net 👍

Configured to mirror the config of the #wikimedia-operations channel using YAML anchors and references. Functionally:

sal:
  channels:
    '#wikimedia-operations': &OPERATIONS
      keys: values
    '#wikimedia-sre':
      <<: *OPERATIONS

Change 572243 merged by Andrew Bogott:
[operations/puppet@production] cloud: hiera: puppetmaster: refactor hiera (for VM instances)

In T245244#5885019, @awight wrote:

This is really strange, but now I get a "Your edit was saved" notification on betawiki, and not the "restored" message. I don't see what I'm doing differently.

With a successfully logged in users @Jakob_WMDE and I found that we were intermittently regularly getting CSRF token failures for just minted tokens that should have been valid. Sounds like it could be directly related to this (session storage) too.

On the lua side of things: You can reproduce this problem by setting the language to almost anything other than a valid one like "uselang=???". The good news is that I couldn't break out of the string so it's not an injection vulnerability AFAIK but this can be fixed rather easily in the lua side. I will try to make a patch.

Change 572250 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [bugfix] let Site('test', 'test) be equal to Site('test', 'wikipedia')

Change 547198 had a related patch set uploaded (by Michael Große; owner: Michael Große):
[mediawiki/extensions/Wikibase@master] bridge: Adjust the size of the Header and close button x

This is really strange, but now I get a "Your edit was saved" notification on betawiki, and not the "restored" message. I don't see what I'm doing differently.

As requested via IRC.

Here's *ahem* a completely different workflow suggestion, I'm just dumping it here for consideration. It glosses over the edit conflict markers, but I'm imagining we include hidden DOM elements which help us do clever things with the resulting content.

Change 571482 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: minify app build

Too bad, T245244: Conflict resolution process ends with incorrect "This page has been restored" doesn't solve the Visual Editor restore issue. I'll unlink as a subtask.

Change 572247 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: update to new component library version

@MMiller_WMF I'm nearly done with data generation for cswiki and I'll have to work on production the other wiki data later today / tonight / this weekend. It takes a while to churn through everything. I've pushed the latest code and data (cswiki only, with most of the data in) here https://deploy-preview-1--newcomertasks-ores-drafttopic.netlify.com (@Tgr and @Catrope, code is here https://github.com/kostajh/newcomertasks-drafttopic/pull/1).

Change 572243 had a related patch set uploaded (by Andrew Bogott; owner: Arturo Borrero Gonzalez):
[operations/puppet@production] cloud: hiera: puppetmaster: refactor hiera (for VM instances)

Based on the current way these issues are appearing, here is a suggestion of how to amend the order and way items load to reduce the jumpiness.

Change 572230 merged by Andrew Bogott:
[operations/puppet@production] puppetmaster: notify apache2 when the hiera.yaml file is updated

For receipts, Kvitto & resa, might be an alternative but it seems to be its own system? https://support.fortnox.se/hc/sv/articles/115005430005

I'm moving this into Needs Code Review after a discussion with @ovasileva.

cas reset his key and registration worked, re-open if a simlar issues is observed

class UserName as ValueObject is a good way to improve strict types in PHP, give us the map of coupling, prepare this "domain" for re-engineering, etc.
But probably this is more than we need for a 1 string? :)
New stateless instantiable UserNameService* is more preferred

Change 572225 merged by jenkins-bot:
[wikibase/vuejs-components@master] Bump version to 0.1.4

Change 572232 had a related patch set uploaded (by Jbond; owner: John Bond):
[operations/puppet@production] admin: add amooney to ldap only group

I had a look at this and applied the change manually and have been able to recreate. I get this error if i make the change but don't restart Apache on the puppet master forcing it to re-read the hierarchy but its fixed shortly after that.

Change 572230 had a related patch set uploaded (by Jbond; owner: John Bond):
[operations/puppet@production] puppetmaster: notify apache2 when the hiera.yaml file is updated

I have a few questions about the acceptance criteria:

So we (@Jakob_WMDE and @Rosalie_WMDE and me) looked at this in some detail. We came to the following conclusions (chip in if I misrepresented anything)

Please provide the missing formats. It is impossible for developers to know them all

I'd appreciate any suggestions for who to contact and what to do next.

Relevant stills of the current loading behaviour:

Change 572220 merged by jenkins-bot:
[mediawiki/extensions/ProofreadPage@master] Rtrim input text

By default pywikibot will do one edit every 10 seconds (or longer if you use parallel processes). This may be overrided by setting -pt:1 (or 0) and some bots runs under this setting. Other bots may not even sleep between edits (they edit continously), though most of them still follow maxlag.

I tried it again, selected 500 files (same stuff, just null edits) and with 467 files remaining I got throttled.

In T243701#5884801, @Ladsgroup wrote:

I have been thinking about this and I think I have a suggestion. bots and tools, should respect maxlag before it reaches the threshold. We need to return the value of the maxlag in the API as well but tool developers should check the maxlag, even if it's 3 or 2 seconds, then wait for that amount and make the next edit after that (or just sleep exactly after the edit is made). This way they slow down before "they reach the threshold and then have to back off the let go back to normal and then they start the flood of edits again and so on and so forth."

No, problem .... there is still time to do it ; ) ..... I see what @thiemowmde means. But I'm not sure if I can implement this. The problem is that there can be precision problems if it is done as I propose, right?

In T243768#5872454, @Jopparn wrote:

Yes, please go ahead and contact the current insurance company.

In T241889#5884626, @Xover wrote:

@WMDE-Fisch Doesn't this just hide the problem? These newlines are coming from somewhere, and I can't think of a valid reason for them, so the root cause really should be fixed imo.

Incidentally, anywhere you add such things it'd be really helpful for others reading the code after the fact if there was a comment explaining why non-obvious stuff like the rtrim() is there. If it's a workaround for a given Phab, then just something like "// rtrim() is needed to work around T 241889".

Currently Widar use a policy of sleeping 3x+1 second if the lag (x second) is higher than one second. PetScan run batches five in parallel, so for a lag of 10 seconds PetScan make 5 edits every 31 second.