Currently the return code of the function is the return code of the
`eval "$restore_trap"` line, whereas semantically we want the return
code of the `gsutil` call. This is not an issue in most cases as the
`set -e` should kick in, but if the function appears as the condition in
an `if` statement the `-e` flag is suspended.
The main use-case right now is that the daily license check is _not_
uploading artifacts.
CHANGELOG_BEGIN
CHANGELOG_END
* add ActionState to the standard library
* use 1 ActionState, 1 get, 1 put in low-level trigger library
* introduce TriggerStateA for updateState
* fix tests and examples for new updateState signature
CHANGELOG_BEGIN
- [Triggers] The ``updateState`` function now returns a ``TriggerStateA``. This
is an action like ``TriggerA``, but doesn't permit emitting commands. Instead
of taking the state as an argument and returning a new state, you can
manipulate the state with ``get``, ``put``, and ``modify``. Any existing
``updateState`` can be ported by replacing ``s -> expr`` in the lambda
expression with ``-> modify $ \s ->``, and then made to look nicer from there
as desired.
See `issue #7621 <https://github.com/digital-asset/daml/pull/7621>`__.
CHANGELOG_END
* some DAML docs for updateState and TriggerStateA
Change the path used to push to the backup gcs bucket to match what is
put by the release script. This needs to get merged before we run the
next daily.
CHANGELOG_BEGIN
CHANGELOG_END
If we don't already have a copy of an artifact in our "disaster
recovery" storage box, put one.
Note: as implemented, this upload mechanism happens only if the release
was successfully verified signature-wise, so this should not result in
us saving broken artifacts. Also, CI does not have deletion or overwrite
access to this bucket, so overall this should be pretty safe.
CHANGELOG_BEGIN
CHANGELOG_END
This PR extends the existing `save_gcp_data` function to handle any
`gsutil` command. This is done to support existence checking using
`gsutil ls` for private artifacts in release checking (`ci/cron`).
CHANGELOG_BEGIN
CHANGELOG_END
* Update JSON API docs to mention multi-party queries
Forgot to include this in #7571. Also includes the changelog which I
also forgot :sadpanda:
changelog_begin
- [JSON API] Queries on the JSON API now support multiple parties just
like the gRPC Ledger API. Single-party tokens are still
supported. Note that command submissions are still limited to a
single party following the restriction on the underlying ledger API.
changelog_end
* Update docs/source/json-api/index.rst
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
* add getCommandsInFlight as a TriggerA action
* immediately update commandsInFlight on emitCommands
- delay until the rule had returned made sense before submitCommands was launched
immediately; this also makes `getCommandsInFlight` more sensible
* remove commands-in-flight argument from high-level Trigger rule
CHANGELOG_BEGIN
- [Triggers] The "commands in flight" or ``Map CommandId [Command]`` argument has been
removed from high-level trigger ``rule`` functions; instead, the current
commands-in-flight can be retrieved with the new ``getCommandsInFlight`` function, which
can be done immediately at the beginning of the rule's ``do`` block to preserve exact
existing trigger behavior.
See `issue #7600 <https://github.com/digital-asset/daml/pull/7600>`__.
CHANGELOG_END
* remove commands-in-flight argument from trigger tests
* update doc examples and copy in compatibility
- compatibility change will most likely entail another flag day in compatibility tests,
replacing last_pre_7456_trigger_version
* update doc text for getCommandsInFlight
* test that getCommandsInFlight gets updated during the rule
* flag day for trigger compatibility tests
sdk-version: 1.7.0-snapshot.20201006.5358.0.0c1cadcf
File: src/CopyTrigger.daml
Hidden: no
Range: 55:11-55:19
Source: typecheck
Severity: DsError
Message:
src/CopyTrigger.daml:55:12: error:
• Couldn't match type ‘TriggerA ()’ with ‘() -> TriggerA ()’
Expected type: Party
-> DA.Next.Map.Map CommandId [Command] -> () -> TriggerA ()
Actual type: Party -> ACS -> () -> TriggerA ()
• In the ‘rule’ field of a record
In the expression:
Trigger
{initialize = \ _acs -> (), updateState = \ _acs _message () -> (),
rule = copyRule, registeredTemplates = AllInDar, heartbeat = None}
In an equation for ‘copyTrigger’:
copyTrigger
= Trigger
{initialize = \ _acs -> (), updateState = \ _acs _message () -> (),
rule = copyRule, registeredTemplates = AllInDar, heartbeat = None}
* match docs on TriggerAState to current usage of these fields
* remove emittedCommands, as commandsInFlight is now kept up-to-date
* zoomed from where?
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
This makes the `daml start` process listen for a key-press. When 'r' is
pressed, the package is re-build, the new package uploaded to the
in-memory sandbox and the codegen re-run.
Note: While we clean previous outputs of the code generation, there is
currently no way to drop previously uploaded packages from the in-memory
sandbox. However, it will take many re-uploads until this will become a
problem.
CHANGELOG_BEGIN
[daml start] You can now press 'r' (or 'r' + 'Enter' on Windows) in the
terminal where `daml start` is running to rebuild the DAR package and
generate JavaScript/Java/Scala bindings and upload the new package to
the sandbox. This frees the user from killing and restarting `daml
start`.
CHANGELOG_END
In preparation for the renaming, we are stripping the DAML prefix. It
is still called SDK and the sdk-version variable keeps existing.
changelog_begin
changelog_end
This PR creates 3 validation modes:
* `Strict`: Specifies that the committer should validate the package
before committing them to the ledger. When using this mode, the
packages committed to the ledger can be fully trusted and do not
have to be validated when loaded into the engine.
* `Lenient`: Specifies that the committer should perform a fast
validation of the packages before committing them to the ledger.
This mode is useful for ledger integrations that cannot handle
long-running submissions (> 10s). When using this mode, the
packages committed to the ledger cannot be trusted and must be
validated every time they are loaded into the engine.
* `No`: Specifies that the committer should not perform any
validation the packages before committing them to the ledger. This
should be used only by non distributed ledgers, like DAML-on-SQL,
where the validation done in the API server can be trusted.
This PR creates 3 preloading modes:
* `Synchronous` : Specifies that the packages should be preloading
into the engine before committed.
* `Asynchronous`: Specifies that the packages should be preloaded into
the engine asynchronously with the rest of the commit process. This
mode is useful for ledger integrations that cannot handle
long-running submissions (> 10s). Failure of the preloading process
will not affect the commit.
* `No`: Specifies that the packages should not be preloaded into
the engine.
CHANGELOG_BEGIN
- [Integration Kit] In kvutils, add metric
daml.kvutils.committer.package_upload.validate_timer to track
package validation time.
CHANGELOG_END
This fixes a bug in the Speedy interpreter. With this change, the
interpreter crashes if it attempts to create a contract containing a
contract key that has an empty set of maintainers.
This is a breaking change approved by Bernhard Elsner.
CHANGELOG_BEGIN
- [LF] (Bug fix) enforce non-empty maintainers in contract key during
contract creation.
CHANGELOG_END
* Support multi-party reads on the JSON API
Given that those aren’t going away and we’re instead doubling down on
this and adding multi-party writes as well, the JSON API needs to
support this. This PR only implements the read side (since the ledgers
do not yet support the write side).
This does not deviate from the approach chosen by the JSON API to
infer the parties from the token, we just don’t error out anymore when
more than one party is passed.
changelog_begin
changelog_end
* Apply suggestions from code review
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
* Remove dependency on doobie_postgres from db-backend
changelog_begin
changelog_end
* Fix offset update
changelog_begin
changelog_end
* Use nonempty sets for parties
changelog_begin
changelog_end
* Fix updateOffset under concurrent transactions
changelog_begin
changelog_end
* Add tests for multi-party websocket queries and fetches
changelog_begin
changelog_end
* fmt
changelog_begin
changelog_end
* Fix perf tests
changelog_begin
changelog_end
* Cleanup
changelog_begin
changelog_end
* Update ledger-service/http-json/src/main/scala/com/digitalasset/http/dbbackend/ContractDao.scala
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
* Move ParsePayload instances, thanks Stephen!
changelog_begin
changelog_end
* More unsubst
changelog_begin
changelog_end
* Fix off by 1 error
changelog_begin
changelog_end
* Remove redundant type annotation
changelog_begin
changelog_end
* fmt
changelog_begin
changelog_end
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
* Update release instructions to follow newest GSG
We've lately integrated the codegens into `daml start`, which made the GSG significantly shorter in turn. Reflect these changes in the release instructions. Also reword some parts where I found the instructions ambiguous on first reading.
CHANGELOG_BEGIN
CHANGELOG_END
* Apply suggestions
CHANGELOG_BEGIN
CHANGELOG_END
* Release another 1.6.0 snapshot
This includes the backported timeout bump from 5cb20c1145.
changelog_begin
changelog_end
* add gsg fix
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
Make the hardcoded timeout for party allocaction/package upload configurable
This is a short term fix to remediate issues with uploading packages
that take a considerable amount of time to decode and validate and
therefore exhausting the 30 seconds.
Adding a maximum record parameter to the ledger API like we already have
for the config management service is not as straight forward for the
package upload, because one has to account for the time in transit as
well. This topic needs further analysis, but in the meantime making the
timeout configurable and setting the default to 2 minutes should provide
enough headroom to alleviate existing issues with package upload timing.
Contributes to #6880
CHANGELOG_BEGIN
[Integration Kit]: The hardcoded timeout for party
allocation and package uploads in the Ledger API Server can be configured via ParticipantConfig and
the default value is now set to 2 minutes. See
`issue #6880 <https://github.com/digital-asset/daml/issues/6880>`__.
CHANGELOG_END
@hurryabit is taking care of 1.6.0-snapshot.20201006.5358.0.0c1cadcf (#7588), so they get pushed back to the end of the line.
Please do not merge this before #7588.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* LF: force `actor` field in Exercise Update to be undefined.
This PR forces the field 'actor' from 'Upate.Exercise' to be undefined
starting from LF 1.5.
This breaking change is approved by Bernhard Elsner and Shaul Kfir.
It will affect only handcrafted LF archives, as no compiler from SDK
1.0.0 or latter made use of this field.
CHANGELOG_BEGIN
CHANGELOG_END
* make TriggerF's Submit emit a command ID instead of accepting one
- LowLevel updated
- interpreter in Scala updated, preserving Message semantics as closely as possible
* remove nextCommandId and all management from high-level Trigger API implementation
* a note about TriggerF and simulateRule
* port submitCommands calls from tests
CHANGELOG_BEGIN
- [Triggers] The CommandIds as accessed from trigger DAML code are now exactly the command
IDs used in command submission to the ledger; as such, they will vary randomly from run
to run of the trigger rule. To enable this, the low-level ``submitCommands`` function
no longer accepts a command ID, instead returning one; there is no change to the
corresponding high-level ``emitCommands`` function, so high-level triggers should only
see improved and easier-to-understand logging.
See `issue #7587 <https://github.com/digital-asset/daml/pull/7587>`__.
CHANGELOG_END
* port Scala-side assertion of trigger test
* rename commandIdMap to commandIdsUsed
* test that command IDs are like the ones we expect from the runner
* [KVL-519] Instrument command service queues
changelog_begin
changelog_end
* Instrument max-in-flight queue
* Document inputBuffer and maxInFlight metrics
changelog_begin
[Sandbox] New metrics tracking the pending submissions and completions on the
CommandService. Check out the Metrics session in the sandbox documentation
for more details. The new metrics are input_buffer_size, input_buffer_saturation,
max_in_flight_size and max_in_flight_saturation.
changelog_end
* Fix compilations issues (1)
* Fix title underline in docs
* Refactoring of InstrumentedSource
- Rename saturation/size to length/capacity to make it more obvious what they are.
- Move the InstrumentedSource to ledger/metrics. Fits there better, with the utilities
there already for futures. Arguable both should move into libs-scala package at some point though.
- Expand the tests and make the tests less flaky. 200 runs complete fine now.
- Inc/dec the capacity counter within InstrumentedSource.
* Add missing copyright header
* Reformat
* Update ledger/metrics/src/test/scala/com/daml/metrics/InstrumentedSourceSpec.scala
Co-authored-by: hanshoglund-da <67470727+hanshoglund-da@users.noreply.github.com>
* Fix title underline in docs (again)
Co-authored-by: Jussi Maki <jussi.maki@digitalasset.com>
Co-authored-by: hanshoglund-da <67470727+hanshoglund-da@users.noreply.github.com>
At the moment, because the signature check appears in a `if` statement,
failed signatures do not actually fail the script and would thus still
result in "success" messages to Slack.
CHANGELOG_BEGIN
CHANGELOG_END
This PR has been created by a script, which is not very smart and does not have all the context. Please do double-check that the version prefix is correct before merging.
@hurryabit is in charge of this release.
CHANGELOG_BEGIN
CHANGELOG_END
* Add metrics for concurrent commands
* Update readme
CHANGELOG_BEGIN
- [DAML on SQL] Add new metrics for measuring the number
of concurrent command executions. The metrics are:
daml.commands.submissions_running, daml.execution.total_running,
daml.execution.engine_running
CHANGELOG_END
Yes, this is how I write Haskell. I'm told it's an improvement over
Bash.
Jokes aside, plan is to chip away at the Bash script, starting with
replacing the outermost loop with a proper "get _all_ releases" call
from Haskell, but I like keeping things working in small steps, and even
long-term I have no desire to reimplement the gpg signature checking
code in Haskell.
I have tested that things still work (on my machine); the only
difference is that we now only get the full output all at once at the
end, rather than one signature at a time. I don't think anyone is
looking at the output in real-time, so this should not be a huge issue.
CHANGELOG_BEGIN
CHANGELOG_END
* use traverseFM for storeSync
CHANGELOG_BEGIN
CHANGELOG_END
* split the transaction seq trial from the selection of random parameters
* sample focused trial
* temporarily enable focused 48% onlyWildcardParties H2 test in CI
- partially reverts b4244036f6 from #7482
* try different PowerShell syntax, reduce trial count to 250
* remove temporary tests
This fixes the parsing of the npm-scope field of the project config,
where a space is accidentally introduced.
CHANGELOG_BEGIN
[Codegen] Fix for an accidentally introduced space in the npm scope of
genreated JavaSript libraries when it was parsed from the daml.yaml
project config.
CHANGELOG_END
This is a preparatory step for moving at least some of the logic of
checking signatures to this script. The reasoning for putting signatures
in the same script basically boils down to "it already has GitHub
pagination".
I also removed the `run.sh` wrapper because it did not add anything
anymore. It used to be useful, but across various changes it's sort of
lost its purpose.
CHANGELOG_BEGIN
CHANGELOG_END
* 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
