See some prior discussion in T3945.

hahaha

I think this should be fixed now, let me know if you're still seeing issues?

I cherry-picked this to stable and upgraded the cluster.

Do we have a "helpful bug report" badge?

This is a valid, compliant JSON-encoding of the string, which allows / to be escaped -- here's the grammar diagram from json.org:

Aha! That's a different error:

Okay, so suppose we decide this represents a flaw in the linter and a user does accidentally write two linters which are "flawed" by suggesting strictly conflicting patches. Maybe they just made a mistake, or maybe they enabled two different linters which they didn't realize have conflicting behaviors, or maybe they intuitively think the rules for deciding which message wins should be different (for example: use the stronger severity; or use the first message raised; or use the message from the first declared linter; or use the message with the shorter replacement text). Or we add a special priority field for this and both messages have the same priority. What should the behavior be?

Suppose the patches literally suggest changing "A" to "B":

When a linter emits two strictly conflicting patches ("Change A to B", "Change A to C"), what behavior do you expect as a user?

See T7962 and T8054 for previous requests to describe problems.

This was fixed in master, I just missed promoting it to stable since the release schedule has been out of whack recently. Should be fixed now.

Yeah, I don't think it's terrible since it should happen very rarely if we do "don't generate" too, and no matter how clever we are it's unavoidable in some cases (even if we policy filter, we might send down a "3", and then by the time the user actually opens the menu or clicks the bell they can no longer see one of them).

Can you show me the complete output on the client with --trace?

Pretty sure this is fixed now, let me know if you're still seeing it at HEAD.

I think they could probably be like 1/2 or 1/3 the size they currently are and still get the point across, maybe.

(This might have some bugs or whatever, idk.)

That's it, I'm all out of "Participant" badges. Sorry if you missed this exciting, limited-time badge!

Is arc up to date? This change affects Arcanist, not Phabricator.

Broadly, this is messy because:

Let me see if I can give you a skeleton for it.

I've decommissioned the old secure.phabricator.com host.

We aren't able to reproduce this.

64c877702 is about 3 months out of date (April 29).

Rolling.

@devurandom, see {I4} if you'd like a personalized status update on this task.

I can't reproduce this.

It sounds like you actually want T731.

We only convey this information through the use of color, which could also cause difficulty for users who do have vision problems.

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/#describe-problems

Sorry, I've only got these "Participant" badges.

In T8943#127919, @chad wrote:

I think you misunderstand what Badges are for.

Happy to accept a diff for this whenever anyone gets around to it.

If the \\ fix above doesn't resolve it, the fix is probably fiddling with the regexps in PhutilConsoleFormatter::formatString(), but I'm not sure how they're misfiring since they work correctly on my machine and I don't see anything ambiguous in the construction.

In phutil_console_format(), we convert ##xyz## to inverted text, but the \ present in the input is intended to prevent this.

I spent 3 seconds on this, but the location where the error occurs and the locations where we know which error message to print are somewhat distant from one another so disentangling this will take a bit of work.

Thanks!