Ok ^ you can see what it looks like above.

Apparently there are no strong opinions about the icon, I'm going to go with step-forward , we can change it if there are objections.

Wouldn't a project 'tag' be appropriate for this?

Unfortunately I didn't find any useful clues in the logs.

@hashar I guess I can take over from here since I'm assigned. Looks like it's clear for deployment...

I've seen a few alerts for the phabricator phd process. It always recovers immediately but there might be something going on with the queue processing. I'll look into it.

In T279718#7350528, @thcipriani wrote:

That's a good question: @mmodell may have a better memory of ^ than me?

In T288956#7350410, @Jdforrester-WMF wrote:

Should we delete it from Puppet then?

Oh I hadn't noticed https://gerrit.wikimedia.org/r/720811... That is unfortunately out of date / obsolete. Phabricator gets that setting from the database:

What icon should we use?

In T288956#7349858, @Jdforrester-WMF wrote:

I imagine we'd want @gerritbot to also state-change tasks into "In Progress" when a Patch-To-Review tag gets added?

For maximum efficiency, replace the xdotool stuff with some applescript to refresh your firefox tab. Or just remove the xdotool commands, but make sure that the refresh function still does exit 0 because that's how it avoids falling into the loop when you run it from the run-on-save plugin.

vs.code settings for use with https://marketplace.visualstudio.com/items?itemName=pucelle.run-on-save

oops, previous updates were accidentally posted to wmf.20's blocker task

sorry for spamming this task with wmf.21 updates, I had the wrong task id somehow

There are some benefits to having this as a status, from my perspective.

It looks like the fix is merged prior to the branch cut, so if I'm not mistaken, it's in wmf.21 and this isn't a blocker anymore.

Should I be concerned about this causing further problems after rolling out wmf.21?

Noted. Thanks @Jdlrobson

since it's a train blocker

So should I be afraid that this is going to break during the train? I's been added as a train blocker and I'm not sure if that was intended to block group 1 deployment or only group2 tomorrow?

should probably just cast to int here¹?

This should now be live on testwikis.

How do you have the settings for "Audit" on https://phabricator.wikimedia.org/settings/user/fgiunchedi/page/emailpreferences/ ?

This change has been deployed to zuul.

https://gerrit.wikimedia.org/r/c/releng/phatality/+/701950/2 should resolve this.

00:00 utc was chosen because it was sort-of the least busy time for phabricator use. It is definitely not a great time for SRE coverage.

I'd say using the phabricator window would be fine. It takes 2 minutes or less to roll out a phab update and there aren't many upstream changes coming down the pipe these days. At any rate that is an available deployment window that's already established and not often utilized. It may not be the most convenient time, so feel free to pick a different one if you prefer.

this change has been deployed.

Deployed and no longer spamming logs. leaving the task open to track any further work but this is no longer a blocker.

Thanks @matmarex

This may be a train blocker (T281159) if the error rate goes up significantly after deploying to group2 wikis, however, it may be isolated to commons in which case I don't expect the error rate to change.

The fix is merged to 1.37.0-wmf.18 and deployed. Fix confirmed by @abi_ and @Tacsipacsi. All that remains is cleanup of affected pages.

In T286866#7230818, @Base wrote:

• A person which is not a project member creates an internal task (that only they and the project members will see — e.g. a WLM UA team member might ask to update respective mailing list with certain emails)

@Aklapper the biggest risk with giving security policy access is that there is no super-admin with overriding access. There is a command line tool to unlock the policy on a given object.

In T287410#7264811, @Izno wrote:

Is this possibly the cause of this error report for Monobook?

This may be an instance of fallout from T287410: ResourceLoaderSkinModule: Skins should not use the legacy styling feature as mentioned by @Jdlrobson in T281158#7253330:

How widespread is the impact of this bug remaining unfixed? If it's a nitch use and we can fix it with a backport in the short term then I wouldn't roll back. On the other hand, if this is causing some fallout elsewhere or triggering major production breakage then definitely roll back.

@Marostegui indeed that's the correct command for making phabricator read-only.

@Krinkle: From my reading, the consensus now seems to be leaning towards reducing / eliminating the comments from gerritbot. Do we need to make a new task for that?

The UBN has been unbroken.

The immediate error is resolved. Not sure if there are more code changes needed to call this resolved. At least it's no longer blocking T281157: 1.37.0-wmf.16 deployment blockers

I was only worried by the "critical section" language in the error because I don't remember seeing that before. Thanks for verifying @Krinkle! 💕

Looks like this was caused by rEWBA90f8a7446019: Add types for files touch in the following commits

This is breaking in production, I'm rolling back the train

I'm not blocking the train for this because it's in the old version (wmf.15) and only one occurrence.