Question about some attributes of a trigger

Questions
,
1

G-d willing

Hello,
Can please give me an example of when we should use the initialize?

Also, can someone please explain to me the updateState of a trigger? When exactly it is executed? How is it different from the rule?

Regarding the heartbeat, can you give me an example of when it is a good idea to use it? When the heartbeat is set to Some $ minutes 5, still, if a contract is created, the rule is being executed right away. So why do I need to use the heartbeat?
In the documentation, it says about the heartbeat Send a heartbeat message at the given interval. What exactly does it mean?

Thanks,

1 Like
2

Hi @cohen.avraham,

You can use the initialize function to initialize the instance of the type for your user defined state. It runs before your trigger performs any other action.
The updateState function is executed whenever a new transaction or command completion is observed by the trigger runner.
Please find an example of the usage for both here: trigger-failure/Trigger.daml at 54ca0edacf5b9bb9415fdff9a14a078d0e106454 · digital-asset/trigger-failure · GitHub

The heartbeat is enabling you to ensure that you run your trigger rule at least once in the period you define. This does not mean that it cannot run more frequently than that. I think you can utilize this in batched processing, aggregation etc. If you pair the heartbeat with an updateState function that only reacts to the MHeartbeat message, you could write a trigger that runs only once per the specified interval. The trigger runner utilizes an internal a timer that generates the MHeartbeat message invoking the execution of updateState and rule.

3 Likes
3

Hi @Mate_Varga, first thank you very much for your answer.
The example you attached is excellent and helped me understand triggers better.

4

Hi @Mate_Varga
What is the advantage of restarting the trigger, like there is in the withFailures function?
Can you give me a good use case so I can understand it?

5

Hi @cohen.avraham,

The advantage is that you do not have to redeploy/restart your trigger from an operational point of view, it only enables the trigger failure state to be reset upon observing a new FailedTriggerStartRequest contract, so processing of the trigger to be continued.