I'm thinking about resolving this by having three states instead:

@epriestley - I have "almost" ready test suite, hovewer I can't work out line ending test with CR/LF endings. - D17814

I think this was fixed by T12659 -- yell if you're still seeing issues?

@johnny-bit Sure, feel free.

Thanks, I'll just keep an eye on this ticket and switch whenever I need to.

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.

I assume based on your comment there isn't a good replacement for whoami until viewer is available on search? (aka I'll keep using whoami until viewer is available as an input to search)

The pathway forward here is probably:

Hi! I'd love to submit diff + better test cases for this case. I have 3 additional test cases and better character class for whitespace.

The patch above fixes the issue, but as you mention, double newlines are also considered whitespace, which is pretty bad and removes every empty line.
Additionally, \r is also covered by \s, so the patch above creates a new issue that is very similar to mine: the rule LINT_TRAILING_WHITESPACE fixes line endings even when the rule LINT_DOS_NEWLINE is disabled.

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

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

👍 testing it now.

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

See also vaguely related T12505.

See also somewhat-similar T12592 and T8918.

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.

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:

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

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

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

@epriestley, what's weird is, I still have this on my bug install, despite having the latest stable updates. I checked, and the migration definitely ran. Thoughts on how to debug this further?

There is a task to create another target rendering engine, but I'm not able to locate it at the moment.

OK. But isn't it weird from an end-user POV to have unparsed remarkup there?
If it's a choice, you can close this issue! Thank you for your quick answer.

This is working as intended. We only have two choices for target rendering, full remarkup or text.

Thank you for the quick response and fixes!

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

Problems do not reproduce when downgrading svn client:

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.

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

Evan, rP52c4715bbcfb solvedthe issue. Losing low-resolution profile images is no problem.
Thanks for the quick solution!

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

https://secure.phabricator.com/rSVNTEST10