This test suite was introduced in #3870 and seems to be extremely
flaky both locally (I get about 16/20 failures) and on CI.
The error is
- should return completions of commands that are submitted after subscription *** FAILED *** (4 seconds, 945 milliseconds)
Set() did not contain all elements of List("5104", "5100", "5105", "5109", "5103", "5106", "5107", "5102", "5108", "5101") (CommandClientIT.scala:330)
After bumping the timeout, I don’t get any failures locally.
Happy to choose another timeout, I have no clue what a sensible value
is here.
* Port FailingCommandsIT to the Ledger API Test Tool
Closes#2850
The FailingCommandsIT suite contains tests for mismatching ledger
identifier (which is already abundantly covered by the Ledger API Test
Tool) and for bad labels in contract creation, both via submit and
submitAndWait.
Some of the tests previously part of the CommandService Ledger API Test
Tool suite have been moved to a new home in CommandSubmissionCompletion
to reflect the fact that those use the submission/completion workflow
instead of leveraging the submit-and-wait alternatives.
There are also suites that for some reason cover subsequent invocations
of the same services but I'm not sure of the meaning of those and I
would drop them, unless we have a good explanation for those.
* Optimize imports
* Move Scala Ledger API client integration tests
Closes#2845
The Scala Ledger API client tests belong to the
//ledger/ledger-api-client package.
* Reduce noise coming from tests
* sandbox: Move SandboxServer's helper classes to the companion object.
And make them `private`, `final`, and non-`case`.
* sandbox: Drop SandboxServer.apply and just call the constructor.
* sandbox: Move the SandboxServer#SandboxState class into the object.
Leave the `resetAndRestartServer` method behind, though.
* Implementation for the configuration management service
- Add configuration generation to the response of SetTimeModel
- Implement the ConfigManagementService
- Implement integration test into test tool
This is still a draft as it has unsolved FIXMEs and
it conflicts with #3744 which should go first.
The main conflict is with changes to PartyAllocationResponse which cannot
no longer reference "domain.PartyDetail" as we would have a cyclic dependency
(participant-state contains Configuration which we point to from domain.ConfigurationEntry).
The still open issues are:
- Revisit PartyDetail
- Naming: LedgerConfigurationService and ConfigManagementService are not talking
about the same configuration and it feels confusing.
- Remove duplication of ConfigurationEntry? Do we need both domain.ConfigurationEntry
and ledger.store.ConfigurationEntry? Only difference is in the types of participantId
and submissionId.
* Address review part 1
* Fix up tests after rebase and address PR review
* Post-merge fixes
* Add missing config MRT checks and fixes to tests
- Check config MRT in InMemoryLedger and SqlLedger
- Use proper source of time in ConfigManagement
- Separate out ConfigManagementServiceIT in sandbox conformance tsets
* Reformat
Closes#2857
- Also deals with the long ignored todo about not using the context
- Attempts at restoring this as a non-flaky test
- Attempts at running the same test across runtime environments
* sandbox: No point creating a class just for the `close` method.
The LedgerApiServer class doesn't actually have much behavior apart from
closing. The `startServer` method is called during construction, which
definitely counts as spooky action at a distance. This change moves that
behavior to `LedgerApiServer.start` (renamed from `LedgerApiServer
.create` to make it more explicit).
There's not much point creating a class for the rest, so all behavior is
now in that `start` method.
* sandbox: Build up a list of "closeables" as the LedgerApiServer starts.
* sandbox: If the LedgerApiServer fails to come up, stop the parts.
* sandbox: Apply @stefanobaghino-da's refactoring suggestions.
* sandbox: Don't log while building the gRPC server; log at the end.
* sandbox: Turns out we should not stop the server when it works.
Facepalm.
* Ledger api test tool party flakiness for multi-participant runs
Caused by synchronize not waiting for parties to fully exist on
all participants.
* Reenable canton test run
* Update canton to 0.5.2
* Revert "Update canton to 0.5.2"
This reverts commit d0e530c652.
* Add package_entries table
* Change PublicPackageUpload event to cover list of packages.
Add PublicPackageUploadRejected.
* Produce new package update events in KeyValueConsumption
* Update signature of uploadPackages
* Cleanup InMemoryKVParticipantState. Add submissionId to uploadPackages.
* Fix up InMemoryKVParticipantStateIT
* Initial ledger dao changes for package entries
Drop the participant_id as we never expect to see
entries of other participants. This should be done
for party_entries as well.
* Drop UploadPackagesResult
* Implement getPackageEntries and refactor callers
* Add maxRecordTime to uploadPackages
* First cut at updating ApiPackageManagementService
* Update tests, wire through the packageEntries
* Don't extend IndexPackagesService in InMemoryPackageStore
It does not implement the full interface and it isn't used
directly as one anyway.
* Drop maximum_record_time from package_management_service
Adding maximum record times touches the whole stack. Leaving
this change to another PR.
* Wire through the removal of maximum_record_time.
And remove dead code from InMemoryKVParticipantState
* Remove checking for duplicate package uploads
This aligns with the behaviour of WriteService.
* Reformat
* Fix PackageManagementService after adding of submission_id to the service
CHANGELOG_BEGIN
- [Sandbox] Restore 0.13.38 logging behaviour.
- [Navigator] Restore 0.13.38 logging behaviour.
- [Extractor] Restore 0.13.38 logging behaviour.
- [Internals] As of 0.13.39, we merged a number of internal JAR files in
the SDK tarball to reduce its size. These jars used to be standalone
JARs you could invoke as e.g. ``java -jar sandbox.jar <args>``. As a
result of merging the jars, they lost their individual ``logback.xml``
configuration file. Although running the jars directly was (and is
still) not supported, note that you can now achieve the same behaviour
with e.g. ``java -Dlogback.configurationFile=sandbox-logback.xml -jar
daml-sdk.jar sandbox <args>``.
CHANGELOG_END
* sandbox/reference-v2: Split `Config` into three.
- Reference v2 CLI configuration
- Standalone API server configuration
- Standalone indexer configuration
* reference-v2: Simplify CLI parsing of TLS config and extra participants.
Turns out we _always_ want to support extra participants. They're
optional, after all.
* Revert "Remove docker bazel target for sandbox (#3802)"
This reverts commit 48a381ca49.
* sandbox: Use the public `openjdk` Docker image rather than GCR's.
Turns out you need to authenticate with Google Container Registry
regardless of whether the image is public or not. We don't want people
to have to bother logging in to GCR just to get Bazel working.
* sandbox: Split the StandaloneApiServer from the StandaloneIndexerServer.
* sandbox: Move StandaloneApiServer's nested classes to its companion.
And make them private.
* reference-v2: Rename `IndexServer` to `ApiServer`.
* sandbox: Move the services into the `apiserver.services` package.
* sandbox: Move SandboxEventIdFormatter's vals to the top.
* sandbox: StandaloneApiServer helper classes don't need to be Products.
* docs: Fix links for LedgerApiServer and Standalone{Api,Indexer}Server.
* sandbox: Delete a misleading comment from `StandaloneApiServer`.
* sandbox: Rename SandboxEventIdFormatter to EventIdFormatter.
* Move all datatypes out of daml-prim
This moves the remaining two modules DA.Types and GHC.Tuple to
separate LF packages with stable identifiers.
The only data types remaining are the ones for typeclasses which will
disappear once we move this to type synonyms.
CHANGELOG_BEGIN
- [DAML Compiler] The modules DA.Types and GHC.Tuple from daml-prim
have been moved to separate packages.
CHANGELOG_END
* Fix codegen tests
* Fix DarReader test
* Fix kvutils tests
* Fix jdbcdao tests
* Fix hs ledger bindings tests
* Add ledger and participant ID to claims
CHANGELOG_BEGIN
- [Ledger] AuthService implementations can now restrict the validity of access tokens to a single ledger or participant.
- [Sandbox] The sandbox JWT authentication now respects the ledgerId and participantId fields of the token payload.
CHANGELOG_END
* Add tests for ledger and participant in claims
* Address review comment
* Address review comment
* Fix tests
* Fix tests
* ledger-api-scala-logging: Fix errors in IntelliJ IDEA.
The Bazel plugin for IntelliJ doesn't seem to be smart enough to be able
to handle a Scala library that is part `src` directory and part
generated code from another Bazel rule. It just ignores the second part.
This means that IntelliJ cannot find the *ServiceLogging classes, as
they're not represented on the Bazel-generated classpath, and so
complains with lots of errors when working on the equivalent Api*Service
files.
To fix this, we can split these in two, compiling the base traits to
`ledger-api-scala-logging-base` and then the generated code separately.
It does result in an extra Bazel dependency for the users of
ledger-api-scala-logging, as Bazel doesn't realise transitive
dependencies for us.
* Release: Add `ledger-api-scala-logging-base` to the Maven list.
* ledger: Document the health checks.
* sandbox: Build a Docker image.
* sandbox: Create a sample Kubernetes YAML file.
* sandbox: Add health probes to the sample Kubernetes configuration file.
Startup and liveness are tested with a simple TCP connection to port
6865. Readiness checks are done with `grpc-health-probe`, which is added
to the Sandbox container image.
* sandbox: Link to kubernetes.yaml in the README and provide a disclaimer.
// changelog removed as it's not actually relevant to users
* sandbox: Don't try and build `sandbox-image-base` on Windows.
* Apply suggestions from code review
Co-Authored-By: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* sandbox: HikariJdbcConnectionProvider.start(), rather than construction.
It's too easy to construct things; I'd like it to be obvious that we're
starting something (in this case a connection pool).
* sandbox: In SqlLedgerSpec, stop ledgers before shutting down PostgreSQL.
* sandbox: Perform JDBC health checks on a timer.
The problem with hooking into existing requests is that if the Sandbox
is running in a load balancer and reports itself as unhealthy, it might
be taken out of the load balancer. Without any requests going through,
it'll never realize it's healthy again, and so will remain thinking it's
unhealthy forever.
* sandbox: Inline SqlExecutor into DbDispatcher.
There's no clear delineation of responsibilities. I'll try and separate
some of this back out again later.
* sandbox: Make it clear that we're "starting" the DbDispatcher.
* sandbox: Simplify the promise-based behavior in DbDispatcher.
* sandbox: Rename `noOfShortLivedConnections` to `maxConnections`.
The timeout for witnessing the party allocation is now increased
to 30 seconds (from 10 seconds). Additionally the LotsOfParties
conformance test is marked as flaky.
* Sandbox: Remove streaming connections
The separate database connection pool for streaming connections
was only used for the active contracts stream. However, a single
db connection was being occupied until the last active contract was
streamed over the Ledger API to the client. This effectively means
that only ever 2 concurrent active contract streams could exist.
No need to say that this is bad design.
The following changes happened:
- remove the db connection pool for streaming connections
- replace the streaming mechanism for active contracts with
the already existing pagination mechanism in JdbcLedgerDao
- change the pagination mechanism to actually use database level
limit and offset instead of doing the pagination "client side"
- configure the HikariDataSource with the metric registry
CHANGELOG_BEGIN
- [Sandbox] Improve loading of active contracts for the Sandbox SQL backend.
CHANGELOG_END
* Extract PaginatingAsyncStream from JdbcLedgerDao for testing
* Reset metrics registry before each test
* sandbox: If the Flyway migrations fail, crash the process.
Otherwise running it in the background can make it look like
everything's OK.
* reference-v2: If the Flyway migrations fail, crash the process.
Otherwise running it in the background can make it look like
everything's OK.
* sandbox: Remove an errant debugging `println`.
* sandbox: Use `DirectExecutionContext.implicitEC`.
* convert party allocation to the new committer pattern
* scalafmt
* Use map with optional values for kvutils input state
We need to do this to detect when a submission has maliciously
omitted an input key.
This is a first step towards making sure that the package ids for
types defined in daml-prim and daml-stdlib don’t change. This PR
mostly adds all the necessary infrastructure for that and moves
GHC.Types and GHC.Prim to make sure it works.
Until data-dependencies are really solid and we have verified that we
no longer have performance issues with an increasing number of Haskell
packages, we still include the source files in daml-prim and then just
rewrite the references.
We will also need to add tests that these packages really have stable
ids but I’ll leave that for separate PRs since this doesn’t make that
much sense anyway until all of the types have moved to stable
packages.
CHANGELOG_BEGIN
- [DAML Compiler] The modules GHC.Prim and GHC.Types from daml-prim
have been moved to separate packages.
CHANGELOG_END
* Track used packages during whole of engine submit
- Introduce MutableCompiledPackages interface
- Add TrackingCompiledPackages that tracks fetched packages
- Make used packages in transaction optional to distinguish between
missing dependencies and empty set of dependencies.
* Reimplement package dependency tracking
- Compute direct dependencies of a package during decoding
- Compute transitive dependencies of a package when adding a package
to engine.
- Annotate the resulting transaction with package dependencies
in Engine.submit.
* Create Ast.Package with proper direct deps in scenario service
While we don't have use for direct dependencies of a package in
scenario service (only Engine.submit needs it), it's better to be
accurate.
This of course overapproximates the direct dependencies.
* Compile a each new package once in ConcurrentCompiledPackages
* Revert "ledger-api-test-tool: The endpoints are mandatory. (#3611)"
This reverts commit 603ee9367b.
* Restore LedgerTestContext requirement
* Exit early if there are no participants to test
* ledger-api-test-tool: Increase the duration when watching health.
This should hopefully stop CI from flaking out.
* reference-v2/sandbox: Avoid unnecessary companion object constructors.
I like indirection… when it does something.
* ledger: Propagate empty health checks throughout the services.
* reference: Remove duplication from the ReferenceServer object.
* ledger-api-common: Actually query a "reporter" in the health service.
* ledger-api-common: Report health per-component when required.
* ledger-api-health: Use a Map to represent components for health checks.
* sandbox: Fix warnings in SqlLedgerSpec.
* ledger-api-common: Throw GrpcHealthService errors inside the Future.
* ledger: Implement health checks against the PostgreSQL connection.
Without proper testing, because I am not great at this.
* sandbox: Remove duplication and fix warnings in PostgresAround.
* sandbox: Test the SQL Ledger's health reporting on failure.
* sandbox: Don't report as unhealthy until 3 connections fail.
* ledger-api-health: Remove unused parts of the API.
Bit of premature design there.
* sandbox: Rename the "ledger" health check to "write".
* participant-state: Add the ReportsHealth trait to ReadService.
* ledger-api-common: `Future.fromTry(Try(…))` -> `Future(…)`.
* ledger-api-common: Make it clearer that StubReporter closes over health.
* ledger-api-common: Explain the HealthService watch tests with comments.
* sandbox: Clean up SqlLedger a bit.
* sandbox: Don't try and stop PostgreSQL twice in PostgresAround.
* bazel_tools: Windows rlocation lookups need to be with forward slashes.
* release: Fix case of "true".
* ledger-api-common: Make `GrpcHealthService::matchResponse` return a Try.
* ledger-api-common: Make `GrpcHealthServiceSpec` async.
* sandbox: Make a couple of DB classes final.
* sandbox: Avoid importing `X._` in PostgresAround.
* sandbox: Add clues to the SqlLedgerSpec's multiple assertions.
* sandbox: If PostgreSQL doesn't come back up, keep retrying.
* sandbox: Remove duplication in SqlLedgerSpec.
* sandbox: In SqlLedgerSpec, actually wait for the health to change.
* sandbox: In PostgresAround, make stopping PostgreSQL idempotent.
* sandbox: Simplify the SqlLedgerSpec to make it work on CI.
It's worth a shot.
* ledger-api-common: Simplify the GrpcHealthServiceSpec a little.
And add a changelog.
CHANGELOG_BEGIN
- [Ledger API Server] Add a health check endpoint conforming to the
`GRPC Health Checking Protocol <https://github.com/grpc/grpc/blob/master/doc/health-checking.md>`_.
- [Ledger API Server] Add health checks for index database connectivity.
- [Participant State API] Add a mandatory ``currentHealth()`` method to
``IndexService``, ``ReadService`` and ``WriteService``.
CHANGELOG_END
* sandbox: Improve the Javadoc layout for DbDispatcher.
* sandbox: Capitalize constants in SqlExecutor.
* ledger-api-health: Convert HealthStatus to an abstract class.
