• I deployed D17774 to secure.
• I verified that rSVNTEST now correctly raised an error because it was backed by a service with muliple hosts.
• I moved rSVNTEST and rHGTEST to a one-host service, securex-legacy.phacility.net.
• I can no longer reproduce any issues against this host.

T12635 had another similar report, and I believe I tracked down and fixed the root cause there.

And thanks for the report! Let us know if you run into anything else..

This should now be resolved at HEAD:

Actually I think there's a real path to this which remains available:

Here's a script which will identify affected users. Output is:

I think some very old users got into a bugged state where their primary email is verified but the "is verified" flag was never set on their account. We saw one of these users on admin.phacility.com earlier, but I wasn't able to identify a way that a modern account could get into this state.

This reproduces for me at HEAD:

The keyboard reticle probably has the same issue but we can figure that out later.

Oh, this actually is the inline reticle, not the keyboard reticle.

Oh, the highlight itself actually is a little off if the reply is threaded. We move the comment up a little bit to make it visually thread a little more cleanly, but the highlight doesn't get a corresponding offset.

I'm going to try putting this on top of everything and using pointer-events: none to fix all the attendant click/hover/select issues.

There are three different highlights at play here, visible in this screenshot:

The Aphlict logs should probably get consolidated here too, they're set up a little weird and don't currently rotate during normal deployments.

It is intentional that daemons shutdown when they aren't doing anything. See T12298. They will be restarted automatically when work becomes ready.

This is a bug in the upstream. D17770 (or some similar patch) should be available later today.

Tasks, projects, owners packages.

This is probably the fix:

It looks like the existing test cases in master fail on PHP 7.1, presumably because of T10929, so that needs to be fixed before I can fix this.

This rule is constructed very awkwardly and I'd sort of prefer to remove it entirely, but I think we can technically fix this without really disrupting things.

No problem, thanks for the report!