Another user coincidentally ran into some questions here yesterday; I'm going to retarget this to take a stab a improving the documentation/description.

Right, you can't user.search for the currently logged-in viewer. If you don't need to know this (you already know the right username or PHID) and were just using user.whoami for convenience you could switch today, but, e.g., in arc we rely on identifying the logged-in viewer with a Conduit call.

The pathway forward here is probably:

I cancelled and reinstated E1486 to force a cache clear with the new code, which seems to have resolved this in production.

Okay, all better now.

I have to cancel your vacation again sorry

Expected output is similar to this:

What does git show show in arcanist/?

I think we're too conservative about invalidating this cache. To reproduce:

The warning seems to be working properly for me locally, so I can't reproduce the issue if the claim is that it doesn't work:

I think it's right:

The expectation is that you should get this prompt when trying to arc commit a change you did not author:

One broad issue is that admin.phacility.com sees a generally high, sustained request rate of almanac.service.search calls (up to dozens per second). I think the uneven performance I've sometimes observed is just load-related, and that this load is sometimes high enough to max out the Apache workers and cause queue stalls.

This is probably the fix, if you want to test it and diff it before I do:

See also vaguely related T12505.

Basically, I think we already have mostly reasonable behavior here (we do all the easy stuff correctly already).

We could retain a separate "@catlover74 is now named @doglover74" record, but I believe it would mostly only be useful in this case, although there is some overlap with T4267 and T1731 (now merged into T12164).

(We could silently rewrite @catlover74 in comments to be stored internally as {mention PHID-USER-asdlnasdlbn}, which would at least partially retain integrity for comments. However, I don't think there's much we can do about commit messages. We currently don't perform this class of invisible rewrite for any other rules -- the remarkup you edit is exactly the remarkup we store. This isn't out of the question, but I'd like a stronger set of motivating use cases for it since I think it's potentially fairly involved.)

Integrity is broken only in case where something literally uses the old username ("the old username ... anything which uses it").

See also somewhat-similar T12592 and T8918.

Can you describe the behavior you expect, given the text of the message? I think this is an issue with the text being unclear, but I'm not sure how you've interpreted it.

Behavior above sound right? I'll shoot you a diff...

Actually, I misread D17678, which just replaced the grey dot with a violet dot in all cases.

That seems to decide that "\n\n" is "trailing whitespace", which doesn't really make sense to me, but [ \t] might work better than \s.

The expected behavior is that environmental variables are passed to subprocesses -- except in the case of T12071. This is true in the general case. If it is not true here, and not a configuration issue particular to your environment, we must have some uniquely incorrect behavior affecting LD_LIBRARY_PATH specifically, so I'm reclassifying this as a bug.

We can look at this in more detail eventually, but I think there's like a 99% chance it's configuration issue which only affects you, not a bug in Phabricator, so it may be a very, very long time before we pursue it.

Per above, I'm pretty confident this is on your end since I can't reproduce it and we don't generate mail like that.

(Ideally, accompanied by new test coverage.)

If you want to test it, I'll accept this change or some substantially similar change upstream:

Attempt to improve the performance of the almanac.service.search call

bin/host download --phid <phid> --save-as whatever.sql.gz

After T12652, rCORGI is here on secure.phabricator.com.

Use of a mail client other than GMail violates international galactic law, so be careful!

As a workaround, you may be able to configure your client to filter on the "body" field containing the special string: @mattflaschen

Something is rewriting your outgoing mail. We do not send mail with a <meta ..> tag (and never have), nor mail which doesn't have a text part (and never have).

The next actions I plan to take here are:

GC has caught up to Conduit and the conduit_methodcalllog table is down to 160MB from ~1GB.

bin/storage renamespace --from phabricator --to whatever --in whatever.sql > whatever.renamespaced.sql

I think the Leylines change didn't actually work because we make the call via the LB so the request appears to coming from outside the cluster.

Deploying Leylines + GC changes to admin now.

I used bin/files migrate to move some old files which were stored in MySQL before S3 was configured to S3. The file blob table is now down to 160MB from 477MB.

A big part of this appears to be that dumping the huge Leylines table locks it, so requests can't record their own Leylines data:

Specifically, I'd like to make these changes:

I think:

Things seem better here for me, although I'm still seeing a couple issues:

This is probably T12071. Does your php.ini set variables_order to something like "GPCS"?

(Also, registration already requires filling out a CAPTCHA if CAPTCHAs are enabled, so adding a second CAPTCHA on this flow shouldn't meaningfully raise the barrier for attackers.)

I suspect these might be "security researchers" who are trying to demonstrate how Phabricator is rife with "critical vulnerabilities".