This is not the right way to think about triggers. You should not write your triggers to react to events, you should write your triggers to “correct the current state”. The logic of the trigger should essentially be along the lines of:
- I have some expectations about rules that should be verified by the current state at all times.
- Get the ACS, check if the rules hold.
- If they don’t, issue commands to correct the ACS so it matches the state I expect.
As a high-level example, if you had a Daml model with a propose/accept pattern in it, you could think about this in terms of events:
Every time I receive a proposal, I accept it.
But that would be subtly wrong and lead to discrepancies in various contexts. A better way to think about it would be:
I expect the ACS to not have any unanswered proposal. I correct the state by accepting all pending proposals.
That will put you in the right frame of mind to write Daml Trigger code that meshes well with the design of both the trigger runner and the available trigger APIs.
Note that in that second approach, it does not matter whether you run the trigger too often, or at specified intervals. All that matters is the current state at the time the trigger runs, and whether that matches your expectations.