* kvutils: Avoid casting `ArgumentCaptor` and friends in tests.
Instead, use generics the way they're intended.
CHANGELOG_BEGIN
CHANGELOG_END
* kvutils: In KeyValueParticipantStateWriterSpec, drop the Option.
This includes the generated docs for the typescipt libraries daml-react,
daml-ledger and daml-types in the documentation presented on
docs.daml.com. Next step is to create better readmes in this libraries.
CHANGELOG_BEGIN
CHANGELOG_END
After some investigation, canton does not currently expose a nice way
to tell ammonite where it should write its files or even better use
the in-memory mode. However, ammonite respects $HOME so we can just
set that to a temp directory which fixes the issue.
changelog_begin
changelog_end
* Split upgrade models into a separate package
This PR splits the upgrade example into 3 packages instead of 2 which
avoids a dependency from the model on the old model. This is explained
in the documentation.
changelog_begin
changelog_end
* Fix typo
Dependencies on other DAML projects are declared with the `dar_dict` attribute of the build rule. This attribute also declares the names by which the `.dar` files are known in the client project, corresponding to the references in the `daml.yaml` config.
The new rule is used build & test the upgrade documentation example code.
changelog_begin
changelog_end
* Include Bazel patch to mark tests as exclusive
This should hopefully avoid rerunning the conformance tests as often
as we do now. While this patch is not applied on Windows (since we get
it from nix), this is not really an issue since most of the exclusive
tests (in particular, all conformance tests) are disabled on Windows
anyway.
I’ve tested this locally accross a couple of runs and I get the
caching I want and looking at the code in the patch, the change looks
very reasonable. I somewhat wonder if it just broke internally at
google because they marked tests as exclusive that should have gotten
no-cache.
changelog_begin
changelog_end
* Disable caching for canton
In the current state of the release instructions, the person in charge
of the release has to figure out how to produce the changelog. This PR
adds more specific (and hopefully simpler) instructions for producing
relevant changelogs.
CHANGELOG_BEGIN
CHANGELOG_END
Currently, on Linux, after the normal build, we try running the release
script (in "dry run" mode). This is to check that the release script not
only compiles, but actually runs. To be honest I'm not entirely sure why
we do that as a separate step (i.e. why does `bazel test //...` not give
us confidence about this script?), but the point of this PR is that,
while there may be some benefit in running this script on normal PRs to
check that we have not broken the release step, there is absolutely no
point in running it _on a release build_, i.e. right after we've used
the same script in "real" ("wet run"? 🤔) mode.
CHANGELOG_BEGIN
CHANGELOG_END
CHANGELOG_BEGIN
[Documentation] Ledger API documentation clarifies how witness_parties
are determined depending on whether CreatedEvents are served as part of
the flat or full transaction stream.
CHANGELOG_END
This PR changes the release version format for snapshot releases to
allow for an optional "build number", i.e. "how many times have we
screwed up this release before this attempt?".
Adding this to the version string should be fine because:
- It is a number, so GHC will be happy.
- It is dot-separated and (manually) incrementing, so all three formats
will sort it correctly.
- The SemVer->GHC conversion only looks at the beginning and ending of
the snapshot string, and this changes the middle.
This is necessary because sometimes we screw up releases (e.g. #4902),
but also because sometimes releases screw themselves up by somehow
corrupting the Windows cache, and so far changing the version number has
been the only way out of that. So far that has meant changing the target
commit, but that's a very poor reason to choose a target commit.
We should not have to include additional code in a release just because
our release process is flaky.
CHANGELOG_BEGIN
CHANGELOG_END
* ledger-api-test-tool: Fix warnings flagged by IntelliJ IDEA.
* ledger-api-test-tool: Open-world mode.
In open-world mode, parties aren't allocated; their names are just
reserved for the test case, so that no other test will accidentally use
the same party name.
This is so we can test ledgers which dynamically allocate parties, such
as Sandbox.
* sandbox: Run conformance tests in "open-world" mode.
This means that the tests don't explicitly allocate parties (except for
a few), instead relying on Sandbox's implicit party allocation feature.
This is not enabled for Sandbox Next yet.
* sandbox-next: Implicit party allocation.
This is added to the command submission service.
CHANGELOG_BEGIN
CHANGELOG_END
* sandbox-next: Don't implicitly allocate pre-existing parties.
* ledger-api-test-tool: Move pre-allocation into ParticipantTestContext.
* ledger-api-test-tool: We can reserve parties or wait for them. Not both.
Make illegal states unrepresentable as early as possible.
* sandbox: Name ApiSubmissionService's private methods a little better.
* sandbox: Move ApiSubmissionService's conditional logic into methods.
* sandbox: Document why we set `implicitPartyAllocation` to `false`.
* sandbox: Document why `implicitPartyAllocation` is dangerous.
This doesn’t really make sense since the main point of targetting an older
LF version is because your server does not support the newer LF
version but including dependencies in newer LF versions makes that
completely useless. In the current state, this also produces a bunch
of errors that look very confusing and while we might be able to fix
them, I don’t think it’s worth doing.
changelog_begin
changelog_end
fixes#4596
* Rework ValueSerializer
- Handle errors directly in the convenience method (it's the only way in which it's used)
- Don't drop the root cause when a serialization error occurs
- Remove outdated comment
CHANGELOG_BEGIN
CHANGELOG_END
* Add alternative with error context for deserialize method
* Make error context evaluated lazily
* Rename inner helper to avoid name clash
This renames methods backing the `ListKnownParties` request to
from `parties`, `getParties` or `listParties` to `listKnownParties`.
CHANGELOG_BEGIN
- [Ledger API Server] Renamed two metrics:
``daml.index.parties`` was renamed to ``daml.index.list_known_parties``
``daml.index.db.get_parties`` was renamed to ``daml.index.db.list_known_parties``
CHANGELOG_END
* sandbox: Add a database test for storing and retrieving parties.
* sandbox: Add database queries for selecting one or many parties.
* ledger-api-test-tool: Add a test for `ListKnownParties`.
* sandbox: Add an endpoint to retrieve a single party's details.
CHANGELOG_BEGIN
- [Ledger API] Added an endpoint to retrieve a single party's details at
``com.digitalasset.ledger.api.v1.admin.PartyManagementService.GetParty``.
Please consult the ledger API reference documentation for more
information.
CHANGELOG_END
* sandbox: Add an endpoint to retrieve a multiple parties' details.
CHANGELOG_BEGIN
- [Ledger API] Added an endpoint to retrieve multiple parties's details at
``com.digitalasset.ledger.api.v1.admin.PartyManagementService.GetParties``.
Please consult the ledger API reference documentation for more
information.
CHANGELOG_END
* sandbox: Getting a single party is a special case of multiple parties.
So let's use that code path and stop duplicating work.
* sandbox: Remove `GetParty`, as it's subsumed by `GetParties`.
"Subsumed" is a great word.
Events in transaction trees should only reference other events
that:
1) are either create or exercise events
2) the requesting parties are a witness of
This applies to recalculated root nodes as well as
the child event ids referenced in exercise nodes.
CHANGELOG_BEGIN
[Sandbox]: fixed projection of transaction trees.
CHANGELOG_END
* Add a warning for data X = Y {..}.
Part of #4718.
changelog_begin
- [DAML Compiler] The DAML compiler now emits a warning when you declare a single-constructor record type where the constructor name does not match the type name, such as ``data X = Y {...}``. This kind of type declaration can cause problems with cross-SDK upgrades because the record constructor name cannot be recorded in the DAML-LF representation. In the future, this warning will be upgraded to an error.
changelog_end
* s/Ctor/Constructor/g
* Deprecate ledger initialization with scenarios
CHANGELOG_BEGIN
[Sandbox] Initializing the sandbox with scenarios is now deprecated in
favor of using DAML Script. The scenario parameter will be removed in
the near future. A warning is logged on startup.
The DAML SDK templates and quickstart guide are using DAML Script.
See the DAML Script migration guide for more information:
https://docs.daml.com/daml-script/index.html#using-daml-script-for-ledger-initialization
CHANGELOG_END
The logic for detecting these needs to be improved but for now this at
least gives a useful error message instead of some internal stacktrace.
changelog_begin
changelog_end
On MacOS using Java 13 (at least that was the only combination where
I’ve managed to reproduce this). Sandbox spits out errors of the
following form in ``daml start``
```
java.net.SocketException: Connection reset
```
This appears to be caused by the TCP requests that we send to detect
whether sandbox has started. Switching to using the ``--port-file``
option makes this issue go away.
fixes#4670
changelog_begin
- [DAML Assistant] In certain configurations ``daml start`` produced
a (harmless) ``Connection reset`` log message. This has now been
fixed.
changelog_end
* sandbox-next: Pull runner configuration into the constructor.
No need to do it on `acquire()` if it's pure.
* sandbox-next: Error if a scenario is provided.
Sandbox-Next doesn't support scenarios, instead favoring DAML Script.
CHANGELOG_BEGIN
CHANGELOG_END
* kvutils: On error opening an envelope, throw the correct message.
CHANGELOG_BEGIN
CHANGELOG_END
* ledger-on-sql: On error when querying state, throw the correct error.
* kvutils|ledger-on-sql: Remove unnecessary curly braces around `throw`.
changelog_begin
- [DAML Assistant] You can now specify options for
Sandbox/Navigator/the HTTP JSON API in ``daml.yaml`` via
``sandbox-options``/``navigator-options``/``json-api-options``. These
options will be picked up by running ``daml start``. This is
particularly useful for specifying ``--wall-clock-time`` and for
specifying a fixed ledger ID during development.
changelog_end
fixes#2993
