• Add a small explanatory comment pointing here.

Also, what is "By Relevance" ?

• Remove the created/modified properties from the raw result row (this is just housekeeping, I don't believe it affects anything).
• Move the _ft_magic strings to class constants (more housekeeping).

I got the gist of this, but the Maniphest stuff is pretty black magic. I'll trust in your test plan.

I also checked for more leftovers in instances/, but it looks like we don't have any non-default paging there.

I've poked around a fair bit locally, although I'm not totally confident I got every combination of paging columns and queries. I think anything that was missed is very likely to produce an explicit error rather than mysterious behavior, so I'm not too worried about it. Stuff to keep an eye on:

• Farewell, Herlad.

🎺 HERE COMES HERLAD 🎺

Old sequence:

On trigger names, I'm currently imagining that we're likely to end up with a "quick" workflow where you just pick some rules for a column and we don't make you name the trigger, and a "slow and thoughtful" workflow where you take time to set things up and name the triggers. Not sure that'll stick or exactly what it'll look like.

• Add SendGrid SMTP to the blocklist.
• Simplify negative/default implementations of supportsMessageIDHeader().

I also vaguely think some mailer API historically rejected mail with a "Message-ID" header with an actual error ("You can't set this header, we're going to set it for you.") rather than just ignoring/replacing it (maybe SendGrid?), but I might be misremembering or that behavior may have changed. We could still always set the header and drop it in the Adapter nowadays, this whole thing is just a nest of hornets and kicking it has pretty limited upside.

I was imagining keeping the Message-ID, while having the first email also include the same value for In-Reply-To — I completely agree that removing the Message-ID would not work out. If the first email always included both fields, thus referencing itself as a reply to itself, I suppose there could be MUAs that would go into infinite loops. So, maybe too risky.

I can imagine that cases like this may exist:

The only effect I can imagine of always setting the In-Reply-To would be to encourage threading where it's not currently happening, so removing the behavior and deleting all these little methods would be very attractive to me if it were my project. :)

There's probably some argument here for removing this behavior and assuming we can never generate a "Message-ID", but I'm hesitant to make changes like that since client threading is largely unknowable black magic which we can not test, and the current approach seems to generally produce acceptable results without an overwhelming amount of collateral complexity.

• Fix "the the" typo.

It worked!

Very happy to see that you guys are working on this, thank you. 👍

This is an unconstructive mess that I don't specifically plan to act on. T13069 and other work may eventually resolve this case indirectly.

report back on whether it mitigates

In T13265#245125, @brhodes wrote:

I merely wanted to have both possible resolutions on the table, one of which was to give the first message the ID later used In-Reply-To.

How old were things before the upgrade? (Roughly: less or more than about a year old?)

This previous behavior violated standards — the In-Reply-To identifier is supposed to be the Message-ID of a previously delivered email — but at least it wove a consistent fiction for mail clients.