Thank you for the response.

I am not asking for "support" per se, so I am not sure the referenced link is applicable for this task. The use case of application/json requests is major, so rejecting it outright as some kind of non-essential fringe "custom code" seems rather strong. The problem is pretty simple and the fix even more so. I am asking you to consider the benefits of parsing a specific content-type request with an appropriate parser. I totally understand that you have priorities, etc., but this is the situation with my team. We have code on GitHub and associated build tools that will probably never move to Phabricator. How can I not consider the need to integrate these "third-party" tools seriously? I am open to suggestions. Worst case scenario is that we maintain a patched version of this class, which for such a trivial change seems ridiculous.

How would separating these transaction types help?

Can you give me a specific example of a query that you believe Facts will be unable to satisfy, or will satisfy less elegantly than parsing a flat logfile on disk?

Can you walk me through how the data is useless? The data is not in a queryable form, but it is complete: it fully captures the state change -- and we use that fact to render strings like "added project x" and "removed project y". To find adds and removes, you perform set differences on the "old value" and "new value". PHIDs only present in one of the two values were added or removed.

I think that promoting Facts to address this problem is a red herring. I agree that Facts offers many advantages for offline processing of transactions. But I do not understand the reasoning for having such arcane and basically useless metadata for maniphest transactions. If you are trying to discourage the direct usage of transaction queries for performance reasons, this is also sensible. However, we need more descriptive data about task history that can only be provided with transaction metadata. Why not fix the problem where it exists? If you are reluctant to add more logic into TaskEditController, I understand that as well. This is a class that is desperate for refactoring.

Please check https://secure.phabricator.com/maniphest/report/project/

Actually, yes. ManiphestReportController lines 95-97.

corrects indentation to two spaces lines 6-8

establishs a default scalar parameter value for source_name

I got this to work as you suggested.