* Consistently display stakeholders for key visibility errors
fixes#6404
As pointed out by Bernhard in #6404, the previous behavior was pretty
weird. If the committer was only a divulgee, we only displayed
stakeholders. If the committer was neither a stakeholder nor a
divulgee, we displayed stakeholders + parties the contract has been
divulged to. Given that only stakeholders can do lookups it makes much
more sense to display them consistently which is what this PR
achieves. I’ve also renamed “disclosed to” to “stakeholders” to make
it very explicit what is shown there.
changelog_begin
changelog_end
* Apply suggestions from code review
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* fmt
changelog_begin
changelog_end
* lalala
changelog_begin
changelog_end
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
fixes#6403
I am not entirely sure why I thought that using `missingWith` makes
sense here but it clearly doesn’t make sense and resulted in a pretty
bad bug where a transaction both succeeded via `submit` as well as
failed via `submitMustFail` which is clearly the wrong thing to do.
This PR fixes this issue and introduces a `notVisibleWith` function
that does the right thing. I’ve also added some comments and an extra
assertion to clarify things a bit.
changelog_begin
changelog_end
* support external anchors
changelog_begin
- `daml docs` now supports an `--input-anchor` argument specifying the
path to a database of external anchors
changelog_end
* Add daml-base-anchors.json to the damlc-dist target
This script was supposed to remove old agents from the Azure Pipelines
UI. It may have been useful at some time (notably, when we used
ephemeral instances, they did not necessarily get to run their shutdown
script), but as it stands now, it's broken. The output from that step
ends in:
```
error: 2 derivations need to be built, but neither local builds ('--max-jobs') nor remote builds ('--builders') are enabled
```
after listing the nix packages it would build. Furthermore, it does not
seem to be useful as I have not seen any spurious entry in the agents
list on Azure since we switched to permanent nodes, on either the Linux
or Windows side (and this would only run on Linux, if it ran).
I'm also not convinced it ever ran, as I used to see a lot of spurious
machines on both Linux and Windows when we did use ephemeral instances.
CHANGELOG_BEGIN
CHANGELOG_END
The nix cache is currently only 3.5GB, and GHC takes a long time to
build, so I think the convenience vs. cost tradeoff is in favour of
keeping things for a bit longer.
CHANGELOG_BEGIN
CHANGELOG_END
This is needed to recover state after the service shuts down or crashes.
We add a method to the RunningTriggerDao to persistPackages. This only
does something in the case of a DbTriggerDao. In any case the Server
keeps a package map in memory as it's required to construct a trigger runner.
Uploads of existing packages is considered harmless.
changelog_begin
changelog_end
* caching: Wait for the cache to evict some values in tests.
Windows, especially, might not do it the first time. Not sure why;
caching is weird.
CHANGELOG_BEGIN
CHANGELOG_END
* caching: Pull out duplicate tests into CacheEvictionSpecBase.
It doesn't seem to be used anywhere. Obviously `git grep jo` returns a
lot of results, so I may have missed something in the noise, but I did a
reasonable effort to look through them.
CHANGELOG_BEGIN
CHANGELOG_END
* caching: Split caches into new files.
* caching: Rename `Cache.from` to `WeightedCache.from`.
* caching: Move `Configuration` inside `WeightedCache`.
* caching: Add test cases.
* caching: Allow for Caffeine builders to be covariant.
* caching: When instrumenting the Caffeine cache, compose, don't inherit.
* caching: Add a size-based cache.
* caching: Extract out common test cases into base classes.
* caching: Use the size-based cache for LF value translation.
CHANGELOG_BEGIN
CHANGELOG_END
* caching: Simplify the eviction tests.
* caching: Increase the encapsulation in CaffeineCache.
* caching: Commas are important.
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
Given that sadbonx-classic came back from the dead my initial
reasoning that we don’t have to include it since it will be gone soon
anyway is obsolete. Therefore, this PR adds both the in-memory and
postgresql variant to the ledger-api-test-tool tests. For other tests,
I did not yet create variants for sadbonx-classic. Not sure how
important that is, we can always add it later.
changelog_begin
changelog_end
Avoid the use of Fragment.const which interprets raw strings as SQL
queries without any checks. Use the `sql` string interpolation which I
found out does the right thing with Strings and other simple types.
CHANGELOG_BEGIN
CHANGELOG_END
* Do not expect a specific source location in ledger-api-test-tool
This broke running the ledger-api-test-tool against older ledgers
since the behavior of Speedy has changed slightly.
This PR changes `assertGrpcError` to accept a regex and uses that to
match for a wildcard in place of a specific location. I’ve gone
through the existing calls and added appropriate levels of escaping.
changelog_begin
changelog_end
* Pass an Option[Pattern] to avoid having to convert back to a String
changelog_begin
changelog_end
This is another refactoring extracted from #6314. This is removing the
`LedgerSession` argument from `LedgerTestSuite`. The goal of this change
is to remove the closures from the `Tests.Tests` type, so it becomes a
plain map of name to test suite, rather than a map of name to
function-that-returns-a-test-suite.
In context, this is another step towards removing the name duplication
that occurs in the `Tests.default` and `Tests.optional` maps. I have
separated this step from the one that actually removes the duplication
because removing the duplication in #6314 was done by turning the maps
into seqs, thereby changing the order in which tests are run, which
caused the flakiness issues I've been investigating over the past week.
This commit does not yet change the order in which tests are run and is
therefore safe from that perspective. It's still a true refactoring.
It's a fairly simple one at that as `LedgerTestSuite` itself never uses
the session, and there was only one subclass that did. The subclass,
`TransactionScaleIT`, only used it to get at one config parameter. In
this PR, that config parameter is instead passed down directly to the
`Tests.default` method.
The other use of the `session` attribute was to extract it from the test
suite in order to pass it to the `run` method of
`LedgerTestSuiteRunner`. This was done right after creating the test
suites and giving them that same session, so we're now skipping that
round trip and just giving the session directly to `run`.
CHANGELOG_BEGIN
CHANGELOG_END
* First draft of constant lifting
changelog_begin
changelog_end
* refactoring
* doing stuff
* run simplifier on template exprs
* remove merge artifact
* Fix ExerciseWithoutActors
* add comments
* fix trace order test
* prefix generated val names with their provenance
* Verification tool bugfix
During the value collection phase, when encountering a record projection on a (yet) undefined value, stop searching this branch instead of throwing an error.
* Bump pattern-match-perf memory limit with cocreature`s blessing
* bump again
* Filter generated identifiers from daml script test runner
changelog_begin
changelog_end
* Fix party literals
* Remove inlineClosedExpr for now.
* Improve comments
* Reset script test locations
* Unhashmap
* disable daml-lf-verify quickstart tests for now
Co-authored-by: Gert-Jan Bottu <gertjan.bottu@kuleuven.be>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Trigger service: Refactor Server.addDar to take encoded dar
This is so we can write the encoded packages to the database if we have
one (without re-encoding them).
changelog_begin
changelog_end
This integrates the time service into DAML script thereby covering the
main piece of scenarios that was missing from DAML script.
This PR does two things (they are very related and doing them together
makes it much easier to test):
1. It “fixes” `getTime` to return the ledger time in static mode by
querying the ledger time service instead of defaulting to the Unix
epoch which is pretty useless and I would consider the old behavior
a bug. We keep the old behavior via the JSON API since there is no
time service.
2. It adds `setTime` to set the ledger time via the time service. This
is only supported in static time mode (sadbonx and other ledgers do
not expose the time service in wallclock mode because changing time
makes it not wallclock) or via the JSON API (no time service).
fixes#6220
changelog_begin
- [DAML Script] DAML Script’s `getTime` now correctly handles time
changes in static time mode and returns the current time by querying
the time service rather than defaulting to the Unix epoch. Note that
when run via the JSON API, it still returns the Unix epoch.
- [DAML Script] Add `setTime` to DAML Script which sets the ledger
time via the ledger API time service. Note that this is only
supported when running over gRPC in static time mode.
changelog_end
In this PR we cleanup the constructor for the speedy Machine.
* We remove the `case` keyword since `Machine` is a stateful class,
* We replace the pre-existing builders with
+ one generic builder `Machine.apply`,
+ scenario specific builder,
CHANGELOG_BEGIN
CHANGELOG_END
This is the last step of the plan outlined in #6405. As of opening this
PR, "old" nodes are back up, "temp" nodes are disabled at the Azure
level, and there is no job running on either (🤔). In other
words, this can be deployed as soon as it gets a stamp.
CHANGELOG_BEGIN
CHANGELOG_END
This is extracted from #6314. This is a simple renaming of a few
classes. The goal here is to have the `LedgerTestSuite#name` match the
key currently used in the `Tests.default` and `Tests.optional` maps so
that we can eventually remove that duplication (after the
`LedgerSession` argument is removed so we can actually construct the
`LedgerTestSuite` objects and ask them their name).
Note that `LedgerTestSuite#name` is [already defined][0] as:
```
val name: String = getClass.getSimpleName
```
In the context of #6314, this is useful to align the existing behaviour
of `--include` with the desired future behaviour of `--exclude`, so we
can use the same names in both. Alternatives could be to remove the
`LedgerTestSuite#name` method and thread the key `String`s through to
the individual tests somehow, or make the `name` field a constructor
argument rather than reconstruct it based on the class name. This
approach of using the class name is the cleanest I could think of.
CHANGELOG_BEGIN
CHANGELOG_END
[0]: d01715bf2f/ledger/ledger-api-test-tool/src/main/scala/com/daml/ledger/api/testtool/infrastructure/LedgerTestSuite.scala (L14)
This is extracted from #6314, but actually has nothing to do with it.
This is removing two functions that are never called, as well as a type
that is never constructed (and the one pattern match on it).
CHANGELOG_BEGIN
CHANGELOG_END
See #6400; split out as separate PR so master == reality and we can
track when this is done. @nycnewman please merge this once the change
is deployed.
Note: it has to be deployed before the next restart; nodes will _not_ be
able to boot with the current configuration.
CHANGELOG_BEGIN
CHANGELOG_END
This is the second PR in the plan outlined in #6405. I have already
disabled the old nodes so no new job will get started there; I will,
however, wait until I've seen a few successful builds on the new nodes
before pulling the plug.
CHANGELOG_BEGIN
CHANGELOG_END
fixes#6384
For now this keeps the GCP bucket as well. I would suggest to keep
that for 1.3 and drop it in 1.4 but I don’t feel particularly strongly
about this so I’m also happy to drop it now.
changelog_begin
- [SDK] The JSON API and DAML on SQL (sandbox-classic) are now
published as fat JARs to github releases. The GCP bucket that
contained the fat JARs will not receive releases > 1.3.
changelog_end
This PR duplicates the linux CI cluster. This is the first in a
three-PR plan to implement #6400 safely while people are working.
I usually do cluster updates over the weekend because they require
shutting down the entire CI system for about two hours. This is
unfortunately not practical while people are working, and timezones make
it difficult for me to find a time where people are not working during
the week.
So instead the plan is as follows:
1. Create a duplicate of our CI cluster (this PR).
2. Wait for the new cluster to be operational (~90-120 minutes ime).
3. In the Azure Pipelines config screen, disable all the nodes of the
"old" cluster, so all new jobs get assigned to the temp cluster. Wait
for all jobs to finish on the old cluster.
4. Update the old cluster. Wait for it to be deployed. (Second PR.)
5. In Azure, disable temp nodes, wait for jobs to drain.
6. Delete temp nodes (third PR).
Reviewing this PR is best done by verifying you can reproduce the
following shell session:
```
$ diff vsts_agent_linux.tf vsts_agent_linux_temp.tf
4,7c4,5
< resource "secret_resource" "vsts-token" {}
<
< data "template_file" "vsts-agent-linux-startup" {
< template = "${file("${path.module}/vsts_agent_linux_startup.sh")}"
---
> data "template_file" "vsts-agent-linux-startup-temp" {
> template =
"${file("${path.module}/vsts_agent_linux_startup_temp.sh")}"
16c14
< resource "google_compute_region_instance_group_manager"
"vsts-agent-linux" {
---
> resource "google_compute_region_instance_group_manager"
"vsts-agent-linux-temp" {
18,19c16,17
< name = "vsts-agent-linux"
< base_instance_name = "vsts-agent-linux"
---
> name = "vsts-agent-linux-temp"
> base_instance_name = "vsts-agent-linux-temp"
24,25c22,23
< name = "vsts-agent-linux"
< instance_template =
"${google_compute_instance_template.vsts-agent-linux.self_link}"
---
> name = "vsts-agent-linux-temp"
> instance_template =
"${google_compute_instance_template.vsts-agent-linux-temp.self_link}"
36,37c34,35
< resource "google_compute_instance_template" "vsts-agent-linux" {
< name_prefix = "vsts-agent-linux-"
---
> resource "google_compute_instance_template" "vsts-agent-linux-temp" {
> name_prefix = "vsts-agent-linux-temp-"
52c50
< startup-script =
"${data.template_file.vsts-agent-linux-startup.rendered}"
---
> startup-script =
"${data.template_file.vsts-agent-linux-startup-temp.rendered}"
$ diff vsts_agent_linux_startup.sh vsts_agent_linux_startup_temp.sh
149c149
< su --command "sh <(curl https://nixos.org/nix/install) --daemon"
--login vsts
---
> su --command "sh <(curl -sSfL https://nixos.org/nix/install) --daemon"
--login vsts
$
```
and reviewing that diff, rather than looking at the added files in their
entirety. The name changes are benign and needed for Terraform to
appropriately keep track of which node belongs to the old vs the temp
group. The only change that matters is the new group has the `-sSfL`
flag so they will actually boot up. (Hopefully.)
CHANGELOG_BEGIN
CHANGELOG_END
It looks like some nix update has broken our current Terraform setup.
The Google provider plugin has changed its reported version to 0.0.0;
poking at my local nix store seems to indicate we actually get 3.15, but
🤷.
This PR also reverts the infra part of #6400 so we get back to master ==
reality.
CHANGELOG_BEGIN
CHANGELOG_END
Nix now requires -L, I’ve gone ahead and just normalized everything to
use -sfL which we were already using in one place.
changelog_begin
changelog_end
CHANGELOG_BEGIN
[DAML Integration Kit]
- LfValueTranslation.Cache now requires separate configuration of lfValueTranslationEventCache and lfValueTranslationContractCache
CHANGELOG_END
Signed-off-by: Brian Healey <brian.healey@digitalasset.com>
In #6378, I erroneously removed what I (and two other people who looked
at the document) thought was a typo. It turns out it wasn't, but I still
believe the existing form was a bit confusing. This is my attempt at
reintroducing and clarifying the original meaning.
CHANGELOG_BEGIN
CHANGELOG_END
* use Profile.Label newtype for typechecked union instead of AnyRef
- includes port of some of interpreter
- demonstrating its efficacy is the compiler error in this commit:
daml-lf/interpreter/src/main/scala/com/digitalasset/daml/lf/speedy/Compiler.scala:267: error: type mismatch;
found : com.daml.lf.speedy.SExpr.SEBuiltinRecursiveDefinition
required: com.daml.lf.speedy.Profile.Label
(which expands to) com.daml.lf.speedy.Profile.LabelModule.Module.T
withLabel(ref, ref)
^
What was likely intended was to write `ref.ref` here; that is the assumption
the `Event#label` rendering function makes, anyway. Now, we type-check that
the labelling matches the renderer.
* let Profile make arbitrary Labels
* fix null and missing `.ref` calls for labelling
* one more null => LabelUnset
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* implicitNotFound message never used
* ritual offering of the dot and parens
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* LF: rename library transaction-scalacheck to transaction-test-lib
CHANGELOG_BEGIN
CHANGELOG_END
* move files in com/daml
* missing change in release/artifacts.yaml
* remove 'com/dam' from the path
The upgrade to various nodejs libraries in
b03cf7b598
seems to have gotten in an inconsistent state (what even are version
boundaries). This PR updates vscode-languageclient to the latest
version which fixes the issue. Apparently that requires a newer
version of @types/vsode as well (even 6.0.x requires that) so I had to
bump that and the engine. This does mean that we now require vscode
1.39.0. Given that this version was released in September 2019 that
seems very reasonable.
changelog_begin
- [DAML Studio] DAML Studio now requires VSCode 1.39 or newer.
changelog_end
