* Regression test for #3485
* Respect CommandId mapping for transactions
* triggers: Fix ExerciseByKey
Make choice nonconsuming, so that no second `T` is created later.
Only execute `dedupExerciseByKey` if `T_` doesn't exist, yet.
* Update list-triggers test
* triggers: Empty commandId on foreign TransactionM
95ccc59b45 (r347287514)
Previously, we use SValue.fromValue for the conversion. However, this
breaks in cases like Numeric where the scale information is lost. By
using the ValueTranslator instead, we avoid this issue.
There is a similar problem in DAML script but I’ll fix that in a
separate PR.
Since the ValueTranslator is package private, this PR moves the
triggers in the engine package.
Previously, we ended up accumulating trace messages which obviously is
not what you want. This PR changes this to replace the tracelog by a
new, empty TraceLog (if there actually was something to trace) and
thereby fixes this issue.
I don’t really want to start adding tests for logging output so for
now this doesn’t have a manual test but if this starts becoming a
problem again, we probably want to add a separate output source to the
trigger runner instead of going via the logger so we can test this easily.
* trigger.Converter avoid exceptions
Refactor `com.daml.trigger.Converter` to consistently use
`Either[String, _]` instead of throwing exceptions to handle conversion
errors.
* Throw ConverterError on conversion error
The only reason for having AbsoluteContractId was that we could get
some more instances in particular `Ord` and `MapKey` but given that
`ContractId` will be a valid key type for the new DAML-LF maps, we can
just use slower implementations for now and switch to Map-based
implementations once that has landed.
fixes#3336
For now, this uses a somewhat adhoc format with one trigger identifier
per line but given that I expect that it won’t be particularly common
to want to do this mechanically this should be sufficient and it’s
trivial to parse.
This is fairly easy to run into so it makes sense to warn about
this. Given that I expect the trigger library will be reasonably
stable in the near future, this is only a warning rather than an
error.
fixes#3244
* Update bazel-common to fix javadoc issues
Specifically, to fix the following error
```
ERROR: /home/aj/tweag.io/da/da-bazel-1.1/ledger-api/rs-grpc-bridge/BUILD.bazel:7:1: in javadoc_library rule //ledger-api/rs-grpc-bridge:rs-grpc-bridge_javadoc:
Traceback (most recent call last):
File "/home/aj/tweag.io/da/da-bazel-1.1/ledger-api/rs-grpc-bridge/BUILD.bazel", line 7
javadoc_library(name = 'rs-grpc-bridge_javadoc')
File "/home/aj/.cache/bazel/_bazel_aj/5f825ad28f8e070f999ba37395e46ee5/external/com_github_google_bazel_common/tools/javadoc/javadoc.bzl", line 27, in _javadoc_library
dep.java.transitive_deps
object of type 'JavaSkylarkApiProvider' has no field 'transitive_deps'
```
* Define Maven deps using rules_jvm_external
* Pin artifacts
* Remove bazel-deps generated targets
* Remove bazel-deps
* Switch to rules_jvm_external targets
* update bazel documentation
* pom_file: There are no more bazel-deps targets
* BAZEL-JVM.md `maven_install` typo
* Add TemplateTypeRep to AnyContractId
* Define Trigger.ContractId t
* Use Trigger.ContractId t
* Implement fromCreated and fromArchived
* instance MapKey TemplateTypeRep
* More efficient ACS access using Map TemplateTypeRep
* ./fmt.sh
* toString and fromString for Identifier
* Replace Identifier by TemplateTypeRep
* TheContractId --> AbsoluteContractId
https://github.com/digital-asset/daml/pull/3245#discussion_r338033546
- We now display `trace` messages so they can be used for debugging.
- I’ve removed the log message from the low-level API since it is
confusing as it is not exposed via the high-level API and somewhat
redundant since you can use `trace` for debugging. If there is a
demand for proper logging support we might want to add it back at
some point.
- We now display errors from speedy properly. This is mainly important
for calls to `error` since we previously lost the error message.
- Logging messages go through a proper logging library now and the
internal debugging stuff is only displayed at debug level so not by default.
- We log failed completions at warning level to ease debugging.
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.
* Generalize AnyTemplate type to Any in DAML-LF
See #3131 for the motivation for this. The tl;dr is that we need
something like AnyTemplate for choice types as well.
Since the protobuf was already more general in anticipation of such a
change, this change only changes the internal AST on the Haskell and
Scala side.
Since AnyTemplate change has never made it out of 1.dev, I updated the
changelog in the LF spec instead of adding a new entry.
* Update daml-lf/spec/daml-lf-1.rst
Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* windows debugging
* more windows debugging
* clean expunge
* don’t cat the config file
* remove comment on type equality
* windows …
* gnah
* foobar
* foobar
* does anything ever work?
* reenable caching
* Do not build daml-lf-ast separately
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.
Having everything in a single file has gotten a bit unwieldly so this
PR splits it up. There is no change in the actual code, this is just a reshuffling.
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 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.
