Does the registeredTemplates field in a DAML Trigger affect the ACS which is threaded through my rule?

Questions
,
1

I’ve created a daml trigger with the registeredTemplates in the Trigger type set to RegisteredTemplates [registeredTemplate @T1] (rather than use AllInDar).

Does that mean that in the ACS passed into my rule I don’t have access to contracts other than instances of T1?

E.g. If I didn’t wish to archive away contracts from another template, T2, then I’d exclude it from the registeredTemplates list (otherwise I believe the trigger would keep firing). Would that then exclude T2 contracts from the ACS? So that getContracts @T2 acs is not going to be populated despite there being such contracts on the ledger visible to the --ledger-party ?

4 Likes
2

registeredTemplates is used as a filter on the subscription to the transaction stream used by the trigger. So if you do not include T2, the trigger will never see transactions containing T2 and therefore those contracts will not be shown in the ACS.

There is currently no way to limit firing the rule to specific events while still updating the ACS. There are two situations if we get an event for T2:

  1. Either your ACS is in a state where your trigger rule will emit commands, then firing it is the right thing to do and that will modify the state in some way, e.g., by adding contracts to the pending set.
  2. Or your ACS is not in a state where your trigger rule will emit commands. The worst thing that can happen here is that you waste some computational resources. For a lot of triggers figuring out if you have to do anything is fairly cheap so this is often not an issue. If you do something computationally expensive here you could consider using the custom user state that stores enough information to make that check cheap again instead of having to recompute that information from the ACS everytime the trigger rule fires.
6 Likes
3

I would propose making this a point in the documentation. In addition I think it would be a useful addition to see pattern matching on an MHeartbeat Message in an example as well as managing some state rather than leaving it unimplemented. Those two went hand-in-hand for me: I needed the message to be passed to the rule in order to be able to match on it, but discarded the previous state through my updateState lambda as I had no need of it.

5 Likes
4

A post was split to a new topic: Using triggers to handle expiration dates