Waiting for triggers to start

How shall one programmatically wait for triggers to start?

One can for example wait for a line (Trigger is running…) in the log to appear but this is not nice, one needs access to the logfile and depends on the actual format of the log.
One can wait for a contract to appear on the ledger that is created somehow by the trigger but different triggers do different things so this cannot really be generalized.

What is the preferred method? Could you maybe add something like a PID file that only exists if the trigger is running (I don’t say this is the ideal solution)?

3 Likes

Could you describe why you want to wait for your trigger to start? Since triggers are state-based rather than event-based you shouldn’t need to wait for them to be started. E.g., if you have some other code that creates contracts that the trigger will react to it should not matter if you create those contracts before or after the trigger has started.

2 Likes

My actual use case is about testing.

  1. I start the Sandbox
  2. I run some script to have a state on the ledger that is good for the trigger to work on
  3. I start the trigger or triggers
  4. There is a bunch of assertions using the functional testing library

For example given a trigger that waits for contract X and exercises choice “doSomething” and this results in contract Y, in step 4 I check whether the func testing lib observers contract X and then Y.
As part of step 4, I could wait more to allow the trigger to start - actually I think this would need a much bigger timeout, which I do not want.

Currently the timeout to observe the creation of contract Y is 10 seconds. This should be plenty.
In theory, increasing the timeout could solve the issue, however what should be a good number and how would one determine it, e.g. 3 minutes or just 1?

Also as mentioned, 10 seconds of timeout is practically enormous even in a real network environment and from the perspective of these tests everything is local. Having this timeout would be enough, if the test had started when it should have - meaning that after the trigger had been started.

1 Like

Here’s an approach that might work as of 1.1.0-snapshot.20200422.3991.0.6391ee9f, though someone who knows better should probably chime in:

  1. Start the sandbox.
  2. Wait for the sandbox to be up and running (say, while ! nc -z localhost:6865; do sleep 1; done)
  3. Start the trigger host. Load all your triggers, including a “pong” trigger.
  4. Run a “ping” script, then run a “check pong” script until it succeeds. You can do that by checking the output-file of the script (Add an --output-file option to DAML Script by cocreature · Pull Request #5590 · digital-asset/daml · GitHub).
  5. You now know that your sandbox is running and the trigger host is ready to react. You can run your “main” script and triggers should run pretty much immediately on a local network.

You may “sign off” after the last transaction from your script with another ping and run the check-pong script in a loop again, though I’m not quite sure what that ping should include to ensure it gets ordered after all the other transactions.

The trigger host (as in the thing that can host multiple triggers) is just a very early prototype and is not shipped in the SDK so I don’t think this really works. And even if you do build it yourself, just because the pong trigger runs doesn’t guarantee that the other triggers have finished starting up.

I think at the moment, creating some kind of contract when the trigger has started is your best option.