Previously, it could happen that the command flow used in the test was
started before the trigger queried the ACS on startup.
Now we wait for the ACS to be queried before starting the commands
flow which fixes this issue.
* Add a first draft of documentation for DAML triggers
The API will still change in a bunch of ways but I’d rather get some
docs in place now and update them as we change things than not have
any docs at all.
* Fix path to daml.yaml
* s/bot/trigger/
* fix source code markers
* Fix tests
* Update docs/source/triggers/index.rst
Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
fixes#3128
Also includes a small bug fix to reenable some tests that I
accidentally disabled in #3127 and fixes deserialization of command
ids in completions which I accidentaly broke when making fromCommandId
return an Optional since that’s what we need for transactions.
This PR adds a first draft of a high-level API for DAML
triggers. There is definitely more work to be done and the design is
absolutely not final. However it already allows expressing the copy
bot fairly cleanly so I would like to merge this in its current
state (or at least without bikeshedding the design too much) and then
iterate upon it.
This makes the API a bit safer and nicer to use. Since this is a
low-level API the constructors are exposed, for the high-level API we
probably want to hide them.
* Infer templateId from createCmd argument
* Infer templateId and choiceName in exerciseCmd
* Use exerciseCmd in ACS test
Add a layer of indirection to test `exerciseCmd` in the ACS test.
The trigger first creates a `AssetMirrorProposal`, only when the
proposal has been created, will it exercise the `Accept` choice to
create the actual `AssetMirror` contract.
* Remove toTemplateId
* getTemplateId --> toTemplateId
* Tuple2 --> AnyContractId
* Run Scala formatter
* Export AnyContractId
* extractTemplateId|ChoiceName
* Support Exercise and Create commands in DAML triggers
This is a bit rough but I want something to experiment with before we
settle on a design and start making the LF changes required to make it
nicer.
It does already allow you to use the original template and choice types.
* Update triggers/runner/src/main/scala/com/daml/trigger/Runner.scala
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
This should hopefully fix some of the flakiness we’ve been seeing on
Windows. Not entirely sure what’s going wrong without the clean but
since this only happens the lack of sandboxing seems like the most
likely difference.
This is a first step towards DAML triggers. At the moment, triggers
can consume (very simplified) create and archive events via the Ledger
API, update a state based on that and emit log mesages at each update.
All of this is likely to change significantly in the future, so I
would prefer to not focus too much on minor details for now.
As a test, I added a simple trigger that tracks active contract ids.
