This deadlocks: the first connection has the revision row locked FOR UPDATE and the second connection is waiting on that lock to clear before its update fires. This is an application-side deadlock and MySQL will not be able to detect it, so the request will appear to hang until the query timeout (or execution timeout) is reached.

Sorry, the only way to influence feature development is through a support pact. See also Planning.

The NULL is explicable if we can somehow queue a HarbormasterBuildWorker between the time it is created by harbormaster.queryautotargets and the time the TYPE_UPDATE applies.

Here are the irregularities that jump out to me for the PHI268 data:

For PHI268, here are the actual diffs for the affected revision:

All normal buildables should be created with containerPHID set properly already in the modern code.

For the Harbormaster races, I'm looking at the containerPHID case first since this is a relatively concrete clue (PHI268).

Unit tests caught one issue with D19059 in the password upgrade engine. The code looked like this:

Please use the Discourse community forum or your organization's Support Pact to get help with support questions.

For PHI332, my test case was:

It isn't currently retroactive: the fix is in transition logic and the transition just didn't trigger before.

On the races:

See also PHI356.

This report doesn't meet the reproduction instruction requirement for modern bug reports.

See also PHI356.

This hasn't blown up in 24 hours and is about to promote, so anything else can be handled in followups.

(Testing "secure" flag in webhooks. 🐑)

See PHI357.

I'm not entirely sure this resolves the original request, but we have webhooks now. See also PHI348 and PHI349. There's some documentation that should publish shortly and the changelog should have more details in the next couple hours.

I'm planning to build T11330 ("policy-blind" webhooks) instead, and deprecate feed.http-hooks. See that task for details.

Seems OK:

(I've muted this task so I shouldn't get mail about it.)

"Quack, quack" said the duck.

We now have Postmark configured as a primary mailer for this domain with inbound (via MX record) and outbound (via cluster.mailers) failover to Mailgun. 📫

"Moo", said the cow.

• PhabricatorMailSetupCheck should be removed, but some of the SES stuff should stick around.

See also PHI347.

I largely agree. This is getting leeway because it's backed by support mana (PHI126 basically just asks for this feature, verbatim). I think the actual change in D19033 is small enough that I don't feel too bad about giving this a shot, but I'd like this feature to see significant use and not generate a lot of confusion/support load if it's going to stay in the upstream. I'm also more comfortable trying this because it's very easy to revert.

See T13069 for followups on mail stamps.

See T13069 for this and other similar use cases.

I'm going to roll this forward into T13069, which discusses remaining work for "mail stamps".

I'm going to roll this forward into T13069.

If this feature doesn't see much use, I'd like to remove or deemphasize it (for example, by moving it to a keystroke or removing the UI and just providing access via !mute) at some point since I think UI space in the curtain is premium real estate. This doesn't need to be 200 mutes per user per day, but I could imagine this seeing essentially zero use.

If we make "Must Encrypt" stateful, that flag should also probably live in this table.

The scope on T13053 didn't end up making it very far in this direction so I think this missed the boat for now.

T11934 plans to add these commands everywhere. If they're available all over the place, it might be less necessary to add reminders.

D19032 now renders D123 in text contexts (plaintext email) as D123 <https://dev.tyrellcorp.com/D123> instead of https://dev.tyrellcorp.com/D123.