A sort of broad issue here is that Herald sometimes knows (or could know, or could guess, or maybe could speculate) that a rule won't do what you expect, but it doesn't tell you.

I think this is about as good as we're going to get, and we've only taken a very small step toward the precipice of a self-aware Herald that hates humankind.

KDE appears to be moving to GitLab (see: https://gitlab.com/gitlab-org/gitlab-ce/issues/53206) and we haven't seen this request from other installs, so I'm just going to close this out.

I think the modern answer here is "use Webhooks". They may not do everything you want if you're writing a chat bot (notably, they intentionally do not currently provide a human-readable text representation of transactions) but there generally suitable for publishing changes to Phabricator objects into a remote system and will produce a program with generally reasonable behaviors and no weird demons lurking under the surface.

Here's a more concise test:

I built my PHP from source in T13232 so this is presumably not a Homebrew issue.

Currently, I think the primary transactions and transactions triggered by Herald are getting different group IDs. They should be the same group ID, e.g. all these transactions should be in the same "group" for the purposes of collecting transactions into effect groups:

(This is mostly for my own notes and contains roughly zero insight.)

If we were just doing personal notification sounds, I think there'd be a good argument for making this a Settings panel.

Per D20533, the major query this UI uses is currently unkeyed (no dateCreated key on transaction tables).

See also T13290. Now that full URIs count as mentions (D20527), the text "Differential Revision: ..." in commits is counting as a mention, and "mentioning" the associated revision.

This stuff is largely resolved, but survived by a few remaining issues in T13290.