Tests depend on D20182.

Note that T6791 has an example of a change where removing the whitespace options is going to cause a behavioral regression. Here's an example:

This report is generally unclear / hard to reproduce / unusual so I'm not sure how to move forward. It's likely mooted by D20181.

See PHI701. This behavior is not ideal:

I'm going to start here, and implement this proposed rule, which I think is the simpler and more intuitive of the proposals:

It sounds like real-time updates will more-or-less moot this.

(See T13251 for followup.)

I believe all (?) of these are now fixed in both master and stable.

Today, this (normally/usually?) only fires against reviewers that the user actually typed in using their real keyboard, so I think we have some kind of reasonable-ish expectation that they believe those reviewers are currently (or soon) active.

Can't wait for unit tests like

This is clearly the smallest possible change that fixes PHI810, but what would be cooler would be detecting "this revision is unapprovable because of the combination of current away statuses and review requirements" so we only show this message when it's definitely a problem. Don't we have most of that code server-side already for deciding when a revision has reached the "approved" status?

Unit test failure is because this needs a small support change in arcanist/, see next diff.

A related issue here is exemplified in https://discourse.phabricator-community.org/t/importing-libphutil-repository-on-fresh-phabricator-triggers-an-error/2391/, which basically amounts to:

Both tables have this key:

I believe we haven't seen more of this in two years, and "make the worker always exit in less than 2 hours" is a more-or-less reasonable remedy. Getting one extra email every two hours also isn't a huge problem even if we do get this wrong.

As of D19748, I'm not aware of any change of size X that requires more than 8X bytes of memory to parse. This isn't ideal, but it's a fair bit better than the 32X in the original report.

Presumably resolved elsewhere by D19503.

No clue how to reproduce this and we haven't seen anything similar since.