* Bump rules_nodejs
rules_nodejs finally added support for module remapping via js_library
so we can kill our custom rule for that.
changelog_begin
changelog_end
* Fix windows
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
This is necessary to at least attempt an upgrade to 2.13 and
generally, I want to keep our rulesets up2date. rules-scala forces the
version of scalatest so we have to bump that at the same time.
This requires changes to basically all Scala test suites since the
import structure has changed and a bunch of things (primarily
scalacheck support) got split out.
Apologies for the giant PR, I don’t see a way to keep it smaller.
changelog_begin
changelog_end
* Add multi-party submissions to the ledger API
CHANGELOG_BEGIN
* [Ledger API] Command submission requests now contain new optional
fields used for multi-party submissions. Such submissions currently
return UNIMPLEMENTED errors, they will be enabled in the future.
CHANGELOG_END
* Adapt Haskell bindings
* Handle the new ledger API fields
* Fix SubmitAndWaitDummyCommand
* Remove unused methods
* Redesign multi-party auth tests
* Remove direct access of request party
* Apply review comments
* Improve protobuf comments
* Multi-party tracker map
* Fix validation logic
* Consistent metric naming
We add the daml-types/daml-ledger libraries as peer-dependencies instead
of dependencies. This will assure that the library is provided by the
importing library and avoid the situation when two different versions of
these libraries are imported by the generated and the user code.
This fixes#8101.
CHANGELOG_BEGIN
CHANGELOG_END
This PR adds coverage for the package management endpoints of the JSON
API.
CHANGELOG_BEGIN
- [JavaScript Client Libraries] The Ledger object (returned by
`useLedger` through the React bindings) has three new methods covering
the package management API: `listPackages` returns a list of all known
packageIDs, `getPackage` returns the binary data of the corresponding
DALF, and `uploadDarFile` takes binary data and uploads it to the
ledger. Note that `uploadDarFile` requires admin access.
CHANGELOG_END
This PR adds TS bindings coverage for the party management methods of
the JSON API.
CHANGELOG_BEGIN
- [JavaScript Client Libraries] The Ledger object (returned by
`useLedger` through the React bindings) has three new methods covering
the Party management API: `getParties` allows users to, based on a
party id (or party ids, as the name suggests) fetch more information
about the party or check for its existence; `listKnownParties` will
return a list of all known parties, and `allocateParty` will allocate
a new party.
CHANGELOG_END
* ledger-api: Use `proto_jars`.
CHANGELOG_BEGIN
- [Ledger API] The Scala JARs containing the gRPC definitions no longer
contain the *.proto files used to generate the ScalaPB-based classes.
CHANGELOG_END
* Create a source JAR for *.proto files in `proto_jars`.
* ledger-api: Publish the protobuf sources as "ledger-api-proto".
CHANGELOG_BEGIN
- [Ledger API] The *.proto files containing the gRPC definitions are now
provided by a new Maven Central artifact, with the group "com.daml"
and the artifact name "ledger-api-proto".
CHANGELOG_END
* release: We don't need the "main-jar" option.
* Bazel: Proto JARs will always have a Maven artifact suffix.
* Bazel: Simplify Protobuf source file TAR and JAR targets.
* Bazel: Extract out Protobuf functions.
* kvutils: Use ScalaPB to generate a Scala JAR for daml_kvutils.proto.
* Bazel: Delete the unused `da_java_binary` rule, and inline `_wrap_rule`.
* Bazel: Factor out Java/Scala protobuf class generation into a helper.
CHANGELOG_BEGIN
CHANGELOG_END
* daml-lf/archive: Use `proto_jars`.
* Bazel: Remove the visibility modifier from `proto_jars`.
It's too confusing. Just make everything public.
* daml-lf/archive: Push protobuf source tarballs into `proto_jars`.
* Bazel: Add comments to the various parts of `proto_jars`.
* daml-assistant: Do unpleasant things with `location` in Bazel.
Addresses security advisory. I upgraded typedoc as well since that
pulls in the older version of highlight.js and I dont like breaking bounds.
changelog_begin
changelog_end
The stream from the JSON API is split into two sections:
1. The unordered section of ACS events.
2. The ordered transaction stream after the live event.
Our assertions assume that we only get 2 but currently we don’t wait
before sending commands so depending on timing, some of the events can
be delivered as part of the ACS section in a different order causing
very confusing assertion failures.
This test fixes this by waiting for the live event indicating the end
of section 1 and thereby forcing everything to come via the ordered
transaction stream.
Verified that this fixes the flakiness with --runs_per_test=50 which
reproduced it fairly reliable before (on CI, never managed to hit it
locally).
changelog_begin
changelog_end
ts/daml-ledger: createAndExercise
Fixes#7966.
CHANGELOG_BEGIN
JavaScript Client Libraries: The Ledger object (defined in daml-ledger,
returned by useLedger in daml-react) now sports an additional method
`createAndExercise`, which lets JS users create a contract and exercise
a choice on it in the same transaction.
CHANGELOG_END
* daml ledger: add a max-inbound-message-size flag for grpc
This new flag allows to set the maximal accepted inbound message size
when using gRPC to interact with a legger.
CHANGELOG_BEGIN
CHANGELOG_END
* added a test
This PR adds encoders to the various types defined in `@daml/types`. The
serde mechanism did not need one so far because all of the types we're
currently exposing map one-to-one to an appropriate (or, I suppose,
tolerable) JS equivalent. This will not be the case anymore with generic
maps, which means that if we want to provide our users with decent types
(I do), we'll need some real encoding/decoding moving forward.
CHANGELOG_BEGIN
CHANGELOG_END
* Haskell: Add hlint rule to suggest foldl' over foldl
`foldl` is lazy in a way that almost never is what you want since it
can cause space leaks without any benefit. `foldl'` does not have this
problem. See https://www.well-typed.com/blog/2014/04/fixing-foldl/ for
more details.
CHANGELOG_BEGIN
CHANGELOG_END
* Fix all existing occurrences of foldl
CHANGELOG_BEGIN
CHANGELOG_END
* Bump timeouts in build-and-lint’s
We’ve seen some timeouts on CI so let’s bump everything to 100ms and
see if that fixes it. If it doesn’t, we can increase those 100ms as well.
changelog_begin
changelog_end
* Fix race on registering open event
changelog_begin
changelog_end
Fixes#7846.
CHANGELOG_BEGIN
- JavaScript Client Libraries: The family of React hooks `useStream*`
was logging every `close` event as an error. However, there are
legitimate cases for the connection to be closed (e.g. the component has
been unmounted). The default behaviour will now be to log only
unexpected disconnects and be silent on deliberate connection closes. The
behaviour can be customized by passing a `onClose` callback; we
strongly recommend passing such a callback to handle connection errors
gracefully.
CHANGELOG_END
* Amend docs to introduce the concept of DAML Connect
CHANGELOG_BEGIN
CHANGELOG_END
* Slightly change how Sandbox is positioned in the app-arch
* Mention integrated drivers in app arch docs
* Lowercase DAML network
This follows up on #7066 and exposes the new underlying multi-key and
multi-query stream functions through the React bindings. Following the
same reasoning as in #7066, we therefore deprecate the existing
functions (with no intention of removing them) as they become redundant.
CHANGELOG_BEGIN
* JavaScript Client Libraries: Updated React bindings to expose the
recent addition of multi-key and multi-query streams in @daml/ledger.
The singular versions are marked as deprecated as they have become
redundant.
The upgrade path for `useStreamQuery` is very straightforward: the
query factory remains optional, but if specified it should return an
array of queries instead of a single query. The array may be empty,
which will return all contracts for that template (similar as not
passing in a query factory). The return values of `useStreamQuery` and
`useStreamQueries` are the same type.
```
useStreamQuery(T) --> useStreamQueries(T)
useStreamQuery(T, () => query, ...) --> useStreamQueries(T, () => [query], ...)
```
The upgrade path for `useStreamFetchByKey` is only slightly more
involved as the return type of `useStreamFetchByKeys` is a new type
called `FetchByKeysResult` instead of the existing `FetchResult`.
`FetchByKeysResult` differs from `FetchResult` in that it contains a
`contracts` field with an array of contracts instead of a singular
`contract` field. (It differs from `QueryResult` in that each element of
the returned array can also be `null`, if there is no corresponding
active contract.) Call sites can be updated as follows:
```
const {loading, contract} = useStreamFetchByKey(T, () => k, ...);
-->
const {loading, contracts} = useStreamFetchByKeys(T, () => [k], ...));
const contract = contracts[0];
```
CHANGELOG_END
* language: `daml ledger` commands against JSON API
This is the first step in offering the JSON API to run `daml ledger`
commands. First, only the `list-parties` command is implemented. The
other `daml ledger` commands will follow in separate PR's.
CHANGELOG_BEGIN
[Assistant] The `daml ledger list-parties` command can now query the
ledger via the HTTP JSON API instead the gRPC API for known parties on
the ledger.
CHANGELOG_END
* resources: Move builders into //ledger/ledger-resources.
Keep the actual constructors in a trait, but instantiate it when working
with ledger code.
This allows us to later introduce an extra "context" type parameter to
ResourceOwner.
* resources-akka: Move the builders in to //ledger/ledger-resources.
* resources: Introduce an abstract `Context` parameter for owners.
This replaces the concrete `ExecutionContext`. While it _can_ be an
execution context, it really doesn't matter as long as we can get at one
somehow.
This is being introduced so we can wrap the context in a container,
either for type tagging or to include extra information.
Because our current context _is_ `ExecutionContext`, and an implicit is
provided to extract it, we can end up with two ways to get the same
value. We use shadowing to prevent this. This problem should go away in
the near future when a new context type is added.
CHANGELOG_BEGIN
- [Integration Kit] The `ResourceOwner` type is now parameterized by a
`Context`, which is filled in by the corresponding `Context` class in
the _ledger-resources_ dependency. This allows us to pass extra
information through resource acquisition.
CHANGELOG_END
* ledger-resources: Move `ResourceOwner` here from `resources`.
* ledger-resources: Remove dependencies from outside //ledger.
* ledger-resource: Wrap the acquisition execution context in `Context`.
So we can add a logging context to it.
* resources: Pass the Context, not the ExecutionContext, to Resource.
* Avoid importing `HasExecutionContext`.
* ledger-resources: Publish to Maven Central.
* resources: Make the small changes suggested by @stefanobaghino-da.
Co-Authored-By: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* ledger-resources: Pull out a trait for test resource contexts.
Saves a few lines of code.
* Restore some imports that were accidentally wildcarded.
* resources: Replace an `implicit def` with a couple of imports.
* participant-integration-api: Simplify the JdbcLedgerDaoBackend tests.
Try and use the right execution context where possible.
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* @daml/types: Improve Unit type
tl;dr: If we ever want to fix the `Query<T>` type from `@daml/ledger`,
we need a better definition of `Unit`.
TypeScript's type system may not be particularly sound, but the type
`{}` still sticks out as being a very special mess. I _think_ it is
something along the lines of
```typescript
type {} = Exclude<object, null> | string | number | boolean;
```
It is definitely not the type of all records or the type of only the
empty record.
I think it is reasonable to expect that the type relation defined by
```typescrupt
type Equiv<T, U> = T extends U ? U extends T ? true : false : false;
```
is extensional equality of types. Unfortunately, it isn't. For
instance, we have
```typescript
Equiv<{}, {[key: string]: string}> == true
```
but the value `{x: 1}` is assignable to type `{}` but not to type
`{[key: string]: string}`.
The type defined by the interface
```typescript
interface Unit {}
```
is a similarly hot mess as the type `{}`. Although they might seem to
be the same, particularly since we have
```typescript
Equiv<{}, Unit> == true and Equiv<Unit, {}> == true
```
here's a way to tell them apart:
```typescript
Equiv<Unit, {[key: string]: string}> == false
```
Thus, I would say the `Unit` type is mildly saner than the `{}` type.
Why does this matter? If we ever want to fix the query `Query<T>` type,
we need to be able to tell the unit type and `TextMap<_>` apart on the
type level. As demonstrated above, this seems impossible if we use `{}`
as the unit type but it is possible if we use the `Unit` type defined
above as the unit type.
Since I couldn't find a single value that is assignable to only one of
`{}` and `Unit` but not the other, this change should not break
anything at all. That said, I'll refrain from a changelog entry.
CHANGELOG_BEGIN
CHANGELOG_END
* Make eslint happy
CHANGELOG_BEGIN
CHANGELOG_END
* add silent_annotations option to da scala bazel functions
* use silent_annotations for several scala targets
* use silencer_plugin instead when the lib isn't used
* use silent_annotations for several more scala targets
* use silencer_lib for strange indirect requirement for running tests
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* silent_annotations support for scaladoc
* react: let user specify reconnectThreshold
Requested by a user on [the forum].
[the forum]: https://discuss.daml.com/t/usestreamquery-disconnecting/1325
CHANGELOG_BEGIN
* JavaScript Client Libraries: Users of the React wrapper can now
specify the `reconnectThreshold` parameter of the underlying Ledger
through LedgerProps. This adds an optional attribute to the
LedgerProps type, so existing code does not need any change to keep
working as before (i.e. using the default 30s value).
CHANGELOG_END
* add test
As requested on [the forum].
[the forum]:
https://discuss.daml.com/t/usestreamquery-disconnecting/1325
CHANGELOG_BEGIN
* JavaScript Client Libraries: `useStreamQuery` and
`useStreamFetchByKey` now accept an optional `closeHandler` callback,
which will be called if the underlying WebSocket connection fails.
CHANGELOG_END
A user has [asked on the forum] how their application could handle
WebSocket errors. The unfortunate response at the moment is that they
can't: our React bindings will just spit out an error log, and that's
it. The current code seems to just assume the stream will eventually
reconnect, but the underlying stream does stop trying if it fails two
times in a row faster than `reconnectThreshold`.
[asked on the forum]: https://discuss.daml.com/t/usestreamquery-disconnecting/1325
In trying to address this, and with the context of at some point
expanding the React bindings to the multi-{key,query} API, I realized
that, given the current structure of the code, I might end up having to
solve this issue four times, so I decided to first factor out the stream
handling logic in the existing code, and I believe this makes sense as a
separate PR.
I should note, however, that this is _not_ a refactoring: as indicated
by the amended tests, this PR actually changes the behaviour of
`useStreamFetchByKey`. I believe this counts as a bugfix, but welcome
any pointer as to why the behaviours of `useStreamQuery` and
`useStreamFetchByKey` should differ with respect to the `live` event.
CHANGELOG_BEGIN
* JavaScript Client Libraries: fix a bug where the `useStreamFetchByKey`
hook would, in some circumstances, report a "ready" state (i.e.
`loading: false`) even though the underlying connection had not yet been
fully established.
CHANGELOG_END
* Fix Numeric encoding and decoding in Scala bindings
fixes#7474
There are a few issues here:
1. We used toString which produces an exponential notation in some
cases which is not supported by the ledger API.
2. On the other hand, we used BigDecimal.exact for decoding which
isn’t completely wrong but more lax than what the ledger API supports
1 and 2 are fixed by switching to the respective functions in
daml-lf/data
3. The tests in ValueSpec were never executed! The tests are split
into a scala_library and a scala_test_suite and ValueSpec ended up in
the library. I’ve split out the utilities from the actual code.
4. The generator for Numeric produced things that are not valid
numerics (e.g. 92233720368547758070000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
showed up in one test) which now fails with the more strict requirements.
changelog_begin
changelog_end
* Apply suggestions from code review
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
* Address review feedback
changelog_begin
changelog_end
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
With the introduction of the standalone JAR, we cannot rely on the
assistant anymore to pass the default logback config. Users can still
override the logback config with `-Dlogback.configurationFile` if they
need something else but this provides a more sensible default logging
config than seeing a ton of debug logs from netty.
changelog_begin
changelog_end
The notion of `close` on `Stream` seems a bit confused at the moment. As
the code stands (without this PR), if you register a listener for
`'close'` events, you get notified when the underlying WebSocket closes
(even though the stream will then try to open a new one and, if it
manages to reconnect, will keep sending `'change'` events), and you do
not get notified when the stream itself gets closed (by calling
`.close()` on it), because the code in `.close()` removes the listeners
before closing the WebSocket connection, and so also before trying to
send a message to `'close'` listeners. Further, calling `.close()` also
does not seem to work as expected, or at least as I would expect: it
will remove all listeners and close the WebSocket connection, but then
it will immediately open it up again (provided that `reconnectThreshold`
milliseconds have elapsed since the WS was last opened), leaking an open
WebSocket connection.
As part of the same confusion, the current implementation also expects
`'close'` listeners on the stream to receive a WebSocket close event, i.e.
of the form `{code, reason}`.
This PR changes the behaviour such that listeners on the _stream_
`'close'` event:
* do not get notified if the WS connection drops but manages to
reconnect.
* do get notified if the stream closes due to a connection error we
cannot recover from, with a `4001` status code.
* do get notified if the stream is closed by calling the `.close()`
method, with a `4000` status code.
This PR also changes the WS termination logic such that calling the
`.close()` method on the stream actually closes the underlying WebSocket
connection.
CHANGELOG_BEGIN
* JavaScript Client Libraries: fix a bug where, upon closing a stream,
the underlying WebSocket connection may not be properly closed.
CHANGELOG_END
This is an attempt to address #7034 & #7036. Strictly speaking, this
does not match their acceptance criteria, as this only supports multiple
queries, not mixed templates.
Because the two new functions can cover the exact same use cases (and
more) as the existing `streamQuery` and `streamFetchByKey`, the latter
are deprecated. The deprecation cycle I suggest is to deprecate them
immediately by annotating them as such in the documentation (done on
this PR).
That's it. I do not think we ever need to actually remove them, nor to
make them print annoying warnings or anything. There is nothing wrong
with the functions as they stand, they just don't fit in the API
anymore.
We could, at some point, move them to a separate documentation page, or
to the boottm of the existing one, but I feel even removing them from
the documentation is unnecessary.
CHANGELOG_BEGIN
- [JavaScript Client Libraries] Two new methods have been added to
`daml-ledger`: `streamQueries` and `streamFetchByKeys`. They are
similar to the existing singular versions, except they can take
multiple queries and multiple keys, respectively, and return a union
of what the corresponding individual queries/keys would have. Because
these new functions can do everything the existing ones can, we are
deprecating the latter, though there is no plan to remove them.
Upgrade path is straightforward:
```
streamQuery(t); => streamQueries(t, []);
streamQuery(t, undefined); => streamQueries(t, []);
streamQuery(t, q); => streamQueries(t, [q]);
streamFetchByKey(t, k); => streamFetchByKey(t, [k]);
```
There is one caveat, though: `streamFetchByKeys` is a little bit less
lenient in the format in which it expects the key. If your existing
code was conforming to the generated TypeScript code we provide,
everything should keep working, but if you were using plain JS or
bypassing the TS type system, it is possible that you used to
construct keys that will no longer be accepted. The new function
requires all keys to be given in the _output_ format of the JSON API,
which is a little bit more strict than the general JSON <-> LF
conversion rules.
CHANGELOG_END
* ledger-api-client: Add integration tests for the simple stuff.
* sandbox-common: Make `SandboxFixtureWithAuth` a mixin.
This makes it useful with `SandboxNextFixture` as well as
`SandboxFixture`.
Also, add types to non-private fields and methods, and make more fields
protected rather than public.
* ledger-api-client: Add tests to make sure the token is passed through.
CHANGELOG_BEGIN
CHANGELOG_END
* sandbox-common: Tokens are for auth, not auth.
The issue in #6940 has been fixed so in theory this should no longer
fail or at least fail with a different error that we haven’t seen yet
:)
changelog_begin
changelog_end
* Add a useFetch.
CHANGELOG_BEGIN
Add a useFetch hook to the @daml/react bindings for when the user knows
a contractId.
CHANGELOG_END
* Update language-support/ts/daml-react/defaultLedgerContext.ts
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
We allow the `offset` field of a websocket message send in response to a
`streamQuery` request to be `null`. Previously this would cause an
exception to be thrown.
CHANGELOG_BEGIN
CHANGELOG_END
