This very patch got deployed on our rather active downstream instance 10 days ago. I have not heard complaints and I've seen tasks and task comments (replies) created via email, so I'm now pretty confident that it does what it should. Thus I'm going to merge it to reduce technical debt a bit more in Phorge.

@avivey: Would you like to give this another review, once you find some spare time? TIA!

Restore an empty line

This exception happens once $rule in the loop foreach ($this->getMarkupRules() as $rule) in PhutilRemarkupBlockRule::applyRules($text) becomes ProjectRemarkupRule. That's where it blows up.

For testing, I deployed the latest revision of this proposed patch in our downstream instance and created a task via incoming plain text mail with attachments - seems to still work as expected so no obvious breakage (yet): https://phabricator.wikimedia.org/T377859

Fix typo

mimemailparser: Check that PHP mailparse extension is installed

The email body says Herald added a comment.
The email subject line header says [Changed Project Column] (not [Commented On]).
So I wouldn't say it is incorrectly attributed.
AFAIK there are no Herald rules which trigger a separate email notification on its own (but I agree that the described behavior also has confused me in the past) as Herald rules are always triggered by some other previous action.

Try to make this a separate branch

@valerio.bozzolan Proposing to decline in favor of T15940: Update copy of external mimemailparser library / D25829: Update mimemailparser from May 2011 version to 8.0.4.
Let's not increase the diff to upstream (13 years difference) even more.

ARRRGH, I locally did this on master branch instead of a dedicated branch. Sorry, it's been a while!

For context, the ManiphestTransaction table in my installation has >10mio entries so some charts do not render but time out. One approach could be Materialized Views but I don't see how that's feasible given the "Project" tag parameter coming into play (and having thousands of project tags in my installation), so my vague followup idea for my installation is to completely disable the code which handles the legacy data only (as creating the modern data does not rely on querying the ManiphestTransaction table), and thus deliberately ignore ancient legacy data from before 2018 for the sake of performance. That's easier to achieve when the upstream spaghetti code doesn't constantly switch between handling legacy and modern/synthetic data.

No clue :)

Stumbled upon https://we.phorge.it/rP95e179d9a4f31b8c5c2cbb4db8f7fa9f2d3867d6 which also mentions

We may not have a commit object for a given identifier if the commit has not imported yet.

So this can indeed happen.

Basically, premising that the constructor of newFromFutures() seems legit, it's not clear to me why its return result should make sense and be compatible with the expected one. If somebody can clarify this, maybe it's at least something more.

So this patch which changes (and hopefully also fixes) definitely broken code will be blocked for good due to lack of a test plan (which I won't be able to figure out)?
Or does anyone can come up with any other option?

Going to abandon for now as I'm not convinced either that this is something worth to change only to make PHPStan happier.
Note that https://we.phorge.it/book/libphutil/function/assert_instances_of/ might be an option when/if I want to look into this again at some future point.

Don't create an empty title array when there is no $query_text

Uhhh you found the place where the empty array comes from! <3 I failed!