See PHI308. See PHI242 and T8644.
A couple of installs have expressed interest in writing rules like this:
When:
[ Something is wrong with the object ]
Take actions:
[ Add comment ][ "Something is wrong with the object. You should fix it by doing X/Y/Z." ]
That is, when an object is in a bad state, cause some kind of non-idempotent side effect (add a comment, fire a webhook, send an email).
The desire is to apply this side effect each time the object transitions into a bad state -- but only when it transitions and "becomes bad".
When written as described above, the rule takes the action every time an object is updated as long as it remains in a bad state: so the warning fires when it becomes bad, but then it fires over and over again unless the badness is fixed immediately.
The rule can be written to run "only the first time" it matches, but then if the object is fixed and later broken again the rule won't catch it again.
T8644#233749 describes a way to implement a latch using a dummy Subscriber or Tag to store state. This gets the right behavior but is impractically complicated.
A cleaner fix to this is to introduce a third repetition policy to supplement "every time" and "only the first time", something like "if this rule didn't match last time". This has the right behavior (like implementing a latch) without the drawbacks (of explicit, external state management).
I'm not brimming with enthusiasm about this because none of the current rules driving this use case seem like especially great solutions to the problems they're aimed at, but, as in D18823 itself, I don't think there's a great deal of peril here and I think there's a large grey area where this is probably better than nothing.
Adjacently, see also PHI276. The Herald test console does not act as the $viewer, but likely should, because we run into trouble trying to access Diffusion APIs in a clustered environment otherwise.
T13041 is also somewhat adjacent here.