I would argue "rename" isn't really "rename" if all linked references don't get updated BUT I also would be super-opposed to things like git history/commits being re-written (and there may be other cases I don't know of that I would be pro/con to). At some point you'd want to draw the line and I, personally, don't have a solid use case for moving the line.

(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.)

I believe I understand now, however then I have one inquiry. Would there be a way to keep some sort of reference between the old username and new one, so if someone clicked/hovered on that mention the lookup would have some context for a rename that occured in the past. Would have to keep a chain then because people might rename more than once.

I did a local test of a rename and the fact that things like what I mention ^ would be a problem are the reason I'm not renaming current (not new) users.

Correct, I may not be 100% on this but I believe they are using a regex (sorry to trivialize if this is true/untrue/complex/etc.) to do some of the linking for things like me saying @enckse here...not to mention commit messages and the like.

I didn't anticipate that, conpherence entries would be.... a lot of stuff to slog through.

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

I think the (potential) opposition is that they'd have to process all the remarkup as well

I've interpreted the text as renaming a user will break references to objects the user has authored/interacted with. As in, a single transaction occurs and user who is named A is now named B, however all objects that were authored/interacted with will still have a reference to user A, which now no longer exists.

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.

Oh hai I'm still busy busy

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

not intentional

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.

Great, thank you so much! :)

It doesn't look like Thunderbird can do this either. I did a "Body" "doesn't contain" "@Mattflaschen-WMF", and it just moves it anyway even if it is a ping (does have an @).

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

I normally do filters in Gmail, which apparently does not support special characters. I'll try to do it in Thunderbird (the main client I use).

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).

It should be in the menu item you wish to make default when you edit the menu

I don't have any pin icon? Where should it be?

Sorry, updated original task with version information. This is just one example message that got flagged, maybe some other messages have plain-text alternate?

Any idea of how to do this on CentOs?

The next actions I plan to take here are:

Which version of phabricator are you running? Email I get have a plain-text alternate, have no meta tag, and are formatted very differently.

variables_order was indeed set to "GPCS". I changed it to "EGPCS" but it has no effect.

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.