1. Remove `BaseError.Impl`, `LoggingTransactionErrorImpl` and `LoggingPackageServiceError`
and instead provide more direct `DamlError` and `DamlErrorWithDefiniteAnswer`.
2. Remove custom implementation of `TransactionError.rpcStatus` and instead provide simpler one in `DamlErr.r.rpcStatus` (which works by first calling `code.asGrpcStatus` and then converting the result to `com.google.rpc.status.Status`).
3. Remove `GrpcStatus.toProto` and instead use `DamlError.rpcStatus`.
4. Use `asGrpcStatus` and `asGrpcError` instead of `asGrpcStatusFromContext` and `asGrpcErrorFromContext` where possible.
changelog_begin
changelog_end
changelog_begin
Ledger API Specification: CreateUser and GetUser endpoints of UserManagementService now return the CreateUserResponse or GetUserResponse messages, whereas previously they were returning the User message).
changelog_end
* SandboxNextFixture replaced by Sandbox-on-X based SandboxFixture
changelog_begin
changelog_end
* Some fixed tests
* No direct dependencies on //ledger/sandbox:sandbox and //ledger/sandbox:sandbox-scala-tests-lib
* Fix after rebase
* Rename SandboxFixture and add a missing dep
* Generate valid party names if hint is empty
* Smaller maxInboundMessageSize
* Added test for empty display name
* SandboxServer is a ResourceOwner
* Uses execution context passed as an input for resource management
* Fixes flaky FlywayMigrations issue with null Thread.currentThread.currentClassLoader
* SandboxServer simplification returns Port instead of ApiServer
* Dedicated PMAllocateWithoutDisplayName for non-Canton ledgers
* Created since Canton does not return empty display names
* VersionClient supports getApiFeatures
This exposes the `features` part of the version service's
`GetLedgerApiVersionResponse` protobuf.
Map the protobuf to user-friendly subclasses of `Feature`,
defined in `c.d.ledger.api.domain`.
VersionClient does not expose experimental features, as they
are meant for internal testing only.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Simon Meier <meiersi-da@users.noreply.github.com>
Co-authored-by: Simon Meier <meiersi-da@users.noreply.github.com>
* upgrade scalapb/netty/grpc/protobuf in proven combination
CHANGELOG_BEGIN
Upgrade scalapb, netty, grpc, protobuf and guava versions
CHANGELOG_END
* bazel reformat
* match grpc version in deps.bzl
* upgrade akka
* keep grpc version to 1.43 that is used in latest nixpkgs-unstable
* rebase and regen
* update SHA for scalapb tarball
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
For consistency with other APIs in this area.
Note that some pre-existing APIs use `List` instead of `Seq`,
but at least those use the same underlying implementation.
CHANGELOG_BEGIN
CHANGELOG_END
Since Scala 2.13.2, Scala introduced built-in support to
manage warnings in a more granular fashion, thus making
the silencer plugin we are currently using no longer
strictly useful. Removing compiler plugins also removes
friction from migrating to Scala 3 in the future. As a
cherry on top, the built-in warning configuration also
allows to check whether a `@nowarn` actually does
anything, allowing us to proactively remove unused
warnings should the need arise.
[Here][1] is s a blog post by the Scala team about it.
Warnings have been either solved or preserved if useful,
trying to minimize the scope (keeping it at the single
expression scope if possible). In particular, all
remaining usages of the Scala Collection API compatibility
module have been removed.
Using the silencer plugin also apparently hid a few
remaining usages of compatibility libraries that were used
as part of the transition from Scala 2.12 to Scala 2.13
that are no longer needed. Removing those warnings
highlighted those.
changelog_begin
changelog_end
[1]: https://www.scala-lang.org/2021/01/12/configuring-and-suppressing-warnings.html
* Split channel configuration from LedgerClientConfiguration
Fixes#12391
The channel configuration now has to be provided separately from the
configuration specific to the ledger client. In this way we avoid
situations where the builder is provided with some configuration
that gets overridden.
changelog_begin
[Scala bindings] The channel configuration has been split from the
LedgerClientConfiguration class. Provide the gRPC channel specific
configuration separately or use a builder. The channel configuration
no longer overrides the builder.
changelog_end
* Fix compilation issues in //ledger-service/...
New year, new copyright, new expected unknown issues with various files
that won't be covered by the script and/or will be but shouldn't change.
I'll do the details on Jan 1, but would appreciate this being
preapproved so I can actually get it merged by then.
CHANGELOG_BEGIN
CHANGELOG_END
* WIP
* Remove the dummy implementation and replace it with an actual working implementation
* Make it compile!
* Add working tests for the user management support in the json api
CHANGELOG_BEGIN
- [JSON-API] Added basic support for the new user management feature of the ledger such that user tokens are now accepted instead of the legacy tokens
CHANGELOG_END
* Simplify the create iou test case and adjust the test case name to be correct
* Add additional test that covers that the overwrite of actAs&readAs still works via the meta object
* Make it work with unauthenticated ledgers too
* Fix compile error & wrong behaviour & add test coverage for non auth ledgers
* Clean up the diff
* Address 66312e9940 (r770782884)
* Address 66312e9940 (r770750653)
* Addressing 66312e9940 (r770751958)
* Address 66312e9940 (r770736671)
* Address 66312e9940 (r770734395) and 66312e9940 (r770783237)
Co-authored-by: Stefano Baghino <stefano.baghino@digitalasset.com>
CHANGELOG_BEGIN
- [User Management]: add support for managing participant node users and authenticating
requests as these users using standard JWT tokens.
CHANGELOG_END
Co-authored-by: Marton Nagy <marton.nagy@digitalasset.com>
Co-authored-by: Adriaan Moors <90182053+adriaanm-da@users.noreply.github.com>
* concurrent: Replace `DirectExecutionContextInternal` with `parasitic`.
* concurrent: Rename `DirectExecutionContext` `parasitic`.
* Use `ExecutionContext.parasitic` instead of `DirectExecutionContext`.
We no longer need the latter.
CHANGELOG_BEGIN
CHANGELOG_END
* Fix formatting.
* [Self-service error codes] Enabled by default
* Flag changed to `use-pre-1.18-error-codes` (disabled by default)
CHANGELOG_BEGIN
[Ledger API Specification] The Ledger API returns enriched error codes (see https://docs.daml.com/error-codes/self-service/index.html)
For backwards-compatibility, a new API flag `--use-pre-1.18-error-codes` is introduced for preserving the legacy behavior for
clients that want to migrate incrementally to the changed gRPC status code responses and error details format.
CHANGELOG_END
* Adapted HttpServiceIntegrationTest
* Renamed `Feature Flag` to `Configuration` in docs
* Fix Daml Script tests
changelog_begin
changelog_end
* Fix Repl functests
changelog_begin
changelog_end
* Fix haskell binding tests
changelog_begin
changelog_end
* Fix CommandClientIT test
* Fixed Sandbox and CommandServiceBackpressureIT tests
Please enter the commit message for your changes. Lines starting
* Adapt //compiler/damlc/tests:repl-functests again
* Fix more tests and address Miklos' comments
* Flag name changed to `grpc-status-codes-compatibility-mode`
* Remove useless flags sandbox-classic
* Sandbox-classic tests fix for ContractKeysIT and ExceptionsIT
* Created 2 deprecated test suites that have the more generic assertions as returned
by the deprecated in-memory backend
* More fixes for CommandServiceIT
* Fixes compilation issue with the deprecated exceptionsIT class for Sandbox-classic in-memory
* Compatibility mode for old test tools
* Change flag name to `use-pre-1.18-error-codes`
* Apply suggestions from code review
Co-authored-by: Miklos <57664299+miklos-da@users.noreply.github.com>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Miklos <57664299+miklos-da@users.noreply.github.com>
changelog_begin
ledger-api-client - The default command tracking timeout is no longer influenced by the deprecated deduplication_time as a deduplication period. Previously if no timeout was being set in the command and deduplication_time was set as the deduplication period then the command tracking timeout was the minimum between the deduplication_time and max tracking timeout.
changelog_end
* For the client binding propagate the full original completion.
Because more fields are added to the completion it gets more difficult to deconstruct it into our own models while keeping the same external API. Because of this, we are propagating the full completion as well
CHANGELOG_BEGIN
java-client-bindings - the original full completion is included in the `CompletionResponse` when available
CHANGELOG_END
Explaining the limits in more detail.
There were some discrepancies between the documentation and the code; in
particular, if there are too many commands in flight, new ones will just
be held in the queue.
CHANGELOG_BEGIN
CHANGELOG_END
* Throw an exception if the submission id is empty in `CommandTracker`
CHANGELOG_BEGIN
CHANGELOG_END
* Generate a submission ID in the `CommandClient` if it's empty
CHANGELOG_BEGIN
CHANGELOG_END
CHANGELOG_BEGIN
- [Ledger API Specification] `Commands.deduplication_time` field has been deprecated, please use `Commands.deduplication_duration` instead.
CHANGELOG_END
* Use the token from incoming requests to update the package list
changelog_begin
changelog_end
* Lazily initialize the ledger client
* Fix ee integration tests
* Fix package reloading behaviour by using a semaphore to check for ongoing updates
* Refactor out the semaphore code into a concurrency utility class
* Use correct locking for the updateTask so every thread always uses an up to date task
* Remove unused imports in utils.Concurrent & remove packages from the tests
* Hide & mark the token file cli option deprecated because we dont need it anymore and only keep it so client deployment code doesn't break
* Fix scala 2.12 build by adding more type annotations
* Update ledger-service/http-json-cli/src/main/scala/com/daml/http/OptionParser.scala
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update ledger-service/http-json/src/main/scala/com/digitalasset/http/PackageService.scala
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Readd pgkManagementClient after it was removed accidentally (but now it's lazy)
* Remove concurrent object & use atomic boolean instead of a mutex because it makes more sense
* Replace semaphore with countdownlatch
* Refactor the caching into a separate class
* Use Instant instead of LocalDateTime
* Remove that ** of bad synchonization and do stupid simple synchronization because it JUST WORKS, besides adapt when we want to reload
* Remove await in tests because it can result in buggy tests
* remove unused code in WebSocketService.scala
* Unhide the access-token-file option as per request of Stefano
* Less implicit jwts per request of Stefano
* Try making some code more readable as by request of Akshay
* Use more shark because it expresses better than flatMaps if I don't need the arg
* Move defs in predicate in WebsocketService.scala around
* Try to minimize diff further in WebsocketService.scala
* Fix build and minimize diff in WebSocketService.scala further
* Minimize diff of function getTransactionSourceForParty in WebSocketService.scala
* Share the ec in WebSocketService.scala to minimize the diff
* Minimize in function predicate in WebSocketService.scala
* Further minimize in function predicate in WebSocketService.scala
* Change some case classes to be normal classes but with apply method
* Update ledger-service/http-json/src/main/scala/com/digitalasset/http/PackageService.scala
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update ledger-service/http-json/src/main/scala/com/digitalasset/http/Endpoints.scala
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Get rid of implicit jwt tokens, the world is already confusing and full of implicits enough
* Improve readability
* Integrate the new LedgerClient which does not depend on a leder id
* Fix tests
* Apply suggestions from code review
thanks to @S11001001
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
* Apply further review comments
* Remove outcommented code
* Deprecate access token file option in the description too
changelog_begin
- [JSON API] The cli option `--access-token-file` is now deprecated. It
is not needed anymore and you can safely remove it. Reason is that
the operations which prior required a token at startup are now done
on demand using the token of the incoming request.
changelog_end
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
* Add the LedgerClientWithoutLedgerId class
* Minimize diff
changelog_begin
changelog_end
* Minimize diff further
* Add missing license header & reformat
* Update language-support/scala/bindings-akka/src/main/scala/com/digitalasset/ledger/client/binding/LedgerClientBinding.scala
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update ledger/ledger-api-client/src/main/scala/com/digitalasset/ledger/client/LedgerClient.scala
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Add changelog
changelog_begin
- [Ledger Client Scala Bindings] A new variant of the LedgerClient class
was added called `LedgerClientWithoutLedgerId`. This class does not
need a ledger id at initialization. It was added to allow skipping
any checks at initialization for use cases where either the
ledger id is not known at initalization or no valid token can be fed
at initialization for checking the ledger id. Furthermore for each
classes `ActiveContractSetClient`, `CommandClient`, `PackageClient`,
`TransactionClient`, `VersionClient` now exists a variant which
doesn't depend on a ledger id at initialization and instead requires
one for every function as parameter. Moreover the existing classes
are extending these classes with overriding the methods and setting
the default of the parameter with the given ledger id from
initialization. The class `LedgerClientWithoutLedgerId` already
makes usage of these variants e.g. `PackageClientWithoutLedgerId`.
changelog_end
* More changelog
changelog_begin
- [Ledger Client Scala Bindings] The function `transactionSource` of the
class `LedgerClientBinding` now optionally accepts a token which is
passed on to the unterlying call.
changelog_end
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* participant-integration-api: On submit and wait, capture a deadline.
We need this deadline to make sure we terminate the stream.
* ledger-api-client: Use the specified expiry time for tracking.
Not the command deduplication time.
CHANGELOG_BEGIN
- [Ledger API Server] The command deduplication time is no longer used
for determining the period of time to track the command before giving
up. Instead, the gRPC deadline is used. If no deadline is provided
(or if the deadline exceeds the command tracker retention period), the
tracker retention period is used instead.
CHANGELOG_END
* ledger-api-client: Keep supporting the `deduplication_time` timeout.
* ledger-api-client: Improve comments in CommandTrackerFlow and its tests.
Co-Authored-By: Miklos <57664299+miklos-da@users.noreply.github.com>
* ledger-api-client: Rename `maxDeduplicationTime` to `maximumExpiryTime`.
* ledger-api-client: Add tests for command tracker timeouts.
* ledger-api-client: Cap the deduplication period at the expiry time.
* participant-integration-api: Make `trackerRetentionPeriod` a JDuration.
* ledger-api-client: Don't use `JDuration` if we can avoid it.
* participant-integration-api: Add a test for command service timeout.
* Use the tracker retention period as the maximum expiry time.
CHANGELOG_BEGIN
- [Ledger API Server] The command service now uses the tracker retention
period (typically specified with the ``--tracker-retention-period``
command-line argument) as the maximum time to wait for a command to
arrive on the completion stream. After this time, the command will
time out, though it may still complete in the future. Previously, the
deduplication period was used, but it was likely the tracker would be
terminated before that anyway.
The default tracker retention period is 5 minutes, unless otherwise
specified.
CHANGELOG_END
* participant-integration-api: Add a test for TrackerMap parameters.
* participant-integration-api: Use `maximumCommandTimeout`.
Instead of `maximumExpiryTime`.
* ledger-api-client: Shorten timeouts in CommandTrackerFlowTest.
