* Extract Ledger API error definitions in //ledger/error-definitions
changelog_begin
SERVICE_INTERNAL_ERROR error code is created in CommonErrors and replaces the usage of LEDGER_API_INTERNAL_ERROR in ledger-api-client (as a fix).
changelog_end
* Tests in //ledger/error do not depend on //ledger/ledger-api-errors
* Remove unused dependency from //ledger/error
changelog_begin
changelog_end
* Address Martino's comment
changelog_begin
changelog_end
Status quo:
ledger-api-domain's domain object contained three classes related to parties:
1. `PartyDetails`, the oldest, which didn't contain the metadata field and was used both in client and indexer code,
2. `ParticipantPartyDetails`, added recently during the participant-local metadata extensions, similar to the `PartyDetails` above but additionally contains the metadata field,
3. `PartyRecord` which held participant-local metadata extensions for a party.
Changes:
1) `PartyDetails` gets renamed to `IndexerPartyDetails` and together with `PartyEntry` gets moved to participant-state-index Bazel package and is removed from client code,
2) `ParticipantPartyDetails` gets renamed to `PartyDetails` and is now used in the client code instead.
3) `PartyRecord` gets moved to participant-local-store Bazel package
changelog_begin
[Ledger API Specification]:
1. Add 'is_deactivated' attribute to participant users.
2. Introduce participant server's local metadata for parties and participant users consisting of:
- a resource version for optional concurrent change control,
- modifiable key-value based annotations.
3. Add experimental update RPCs for parties and participant users:
- participant user's modifiable fields are: 'primary_party', 'is_deactivated', 'metadata.annotations',
- party's modifiable fields are 'local_metadata.annotations'.
4. Discourage use of 'party_details.display_name' in favor of using party's metadata annotations.
changelog_end
Other notes:
- no-op updates are allowed,
- update paths are resource relative,
- as annotation deletion is by providing an key with the empty string value,
- as a corollary, only non-empty strings are valid annotation values.
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
