Attaching screen shots of the rule and the task that I think should have triggered it:

I can confirm, Rule says it passed and it emailed me, but I received nothing.

I can't reproduce this. I made this rule:

I then created a task:

The rule applied in the transcript:

And email was generated to the affected user:

I'll dig around the transcripts on your instance and see if I can come up with anything.

Here's why you didn't receive the mail:

RECIPIENTS
! oliver (Oliver Dain)

• This recipient is the user whose actions caused delivery of this message, but they have set preferences so they do not receive mail about their own actions (Settings > Email Preferences > Self Actions).

When you disable self-mail, Herald personal rules ("Send me an email") are stronger than the preference but global rules ("Send email to: ...") are not.

Changes associated with T5791 and T8726 will make this more clear, by making Herald transcripts use more specific language and better surfacing routing rules for outbound mail.

To get the behavior you expect, you can either:

• Use a personal rule (which is stronger than your preference).
• Change your preference Settings → Email Preferences → Self Actions.
• Use the rule as-is, and accept that it won't send you mail about your own actions.

Oh, I thought all Herald rules were stronger than preferences.

Thanks for the quick debugging. However, I don't think that fixes my real problem (not your fault since I didn't tell you what that is). The rule was originally to trigger an email to a mailing list user (a PagerDuty integration email specifically). That "user" does not have the don't email for self actions action set (and even if they did, I'm the one creating the bug so it shouldn't apply). Those emails weren't going through. So I changed the rule to email me as a debugging step and found that I'm not getting the email so figured that was the root cause. As you suggest, if I change my preference so I get emailed on self-actions I then do get emails. However, if I change the email back to the mailing list it is not getting emails. Perhaps there's something else blocking these??

Specifically, I change the herald rule so the "user" who should get email is "customer_support_pagerduty" but those emails are not making it through. Specifically, task T1603, which was created after the change was not delivered. I've manually sent emails to that address from my account and can verify that emails do make it to that account and show up in PagerDuty, so I think the email isn't being sent from the Phab side.

BTW: If there are logs or something I can look at on my side to debug I'm happy to do that if you point me in the right direction.

It looks like T1603 on your install has a project visibility policy (i.e., the task is visible to members of a specific project). However, I think the user customer_support_pagerduty is not a member of the project, so they can not see the task. (I'm just looking at the database here, so it's possible I got the WHERE clauses wrong.)

Herald global rules are not stronger than policy rules, and will not send mail to users about objects they can't see, so this behavior is expected if that's the case. Does that sound plausible?

See also T8812 for a similar case.

Changes associated with T8726 should also make this more clear: the transcripts will start getting per-target breakdowns of actions taken, and show that users were excluded because they can't see the object. Currently, the users "pass" the Herald rule but get silently dropped before mail generates.

Specifically, you could get the behavior you want by changing the visibility policy of the task (so the user can see it) or adding the user to the project (so they satisfy the current visibility policy).

Suggestion makes sense, but does not seem to have worked. I added the user in question to the project:

Then created a bug:

But it never showed up in PagerDuty.

I suspect the issue is some stupid config issue like project permissions you suggest but don't know how to debug. I feel bad asking you to do it for us, but don't know what the alternative is. Maybe there should be some logs visible to admins or something so we can debug this kind of thing ourselves? In the meantime, any help you can provide would be great.

Test above wasn't quite right. I have now added the user to the "Signifyd Employees" project as well:

and as per above that user is also a member of the "User Facing Bugs" project. I then created yet another test task:

but still no dice.

Never mind! Not only did my latest test task come through, all the previous ones did too. There was a few minutes delay but it seems to be working now. Thanks a ton for you help.

(would love to see a feature that allows admins to see debug logs and such so we could debug this ourselves)

I'm learning stuff here today too, not a waste at all.

Upcoming changes related to T5791 and T8726 should increase debug-ability, but giving web users access to mail is tricky while still respecting policies (e.g., administrators shouldn't be able to violate policies by just reading other users mail) and limiting the ability for an attacker to escalate access (e.g., an attacker who gets an admin account shouldn't have a blank check to access every other account by reading other users' "Welcome" or "Password Reset" mail).

We will probably give instance administrators more tools in the long run, but the major focus for now is making Herald edge cases and mail routing rules more clear to all users.

Just to follow up on this, the transcript will show this at HEAD once T8726 lands:

This task made for a good read.