Ledger API Error Code Backwards Compatibility

Questions
1

Hi all,

We had a VMWare DLT running DAML Connect 1.11.1. We previously had a DAML application, with daml.yaml:

sdk-version: 1.11.1
name: daml-app
source: daml
parties:
  - Alice
  - Bob
  - Charlie
  - David
version: 0.0.2
dependencies:
  - daml-prim
  - daml-stdlib
codegen:
  java:
    package-prefix: xx.xx.xx.xx
    output-directory: ../src/generated/java
    verbosity: 2

We had a workflow, where if we attempted to fetch a contract which did not exist, it would return an error as below:

io.grpc.StatusRuntimeException: INVALID_ARGUMENT: Command interpretation error in LF-DAMLe: dependency error: couldn't find contract ContractId(00e86b0cebaf72460abdb36ac73f2e32cdbd253652420949b8b6671360d373af2a). Details: N/A.

We then upgraded our DLT platform to DAML Connect 1.14. We kept the same application, with the same daml.yaml file. However, the same workflow resulted in error:

io.grpc.StatusRuntimeException: ABORTED: Command interpretation error in LF-DAMLe: Contract could not be found with id ContractId(00c89a27a7d5af4d8d98ef126354b1b1bba4067a0de943445481a6dabd4ddd4596). Details: N/A.

This change was not mentioned in the release notes and we came across it by chance as it broke one of our backend systems. We also attempted to set the build-options to force target 1.11, however, we still received the new error code.

I was wondering whether we can expect more changes of this nature or this a bug as it causes us a lot of problems with backwards compatibility.

Regards,
Zoraiz

1 Like
2

The first item in the “Bugfixes” section of the 1.12.0 release notes reads:

which may be what’s hitting you here?

As a heads up, the (as of yet preliminary) release notes for 1.15 also have a top-level bullet point that reads:

though I don’t personally know more about that.

4 Likes
3

The error codes (ABORTED, INVALID_ARGUMENT) are part of the Ledger API as they are reported as structured information on completions. As such, the desired state would be to keep them stable and fully backward compatible.
As you can see from @Gary_Verhaegen 's quote above, we have made a few small changes in the past to get rid of some of the worst inconsistencies already, but our API specs on error codes are still not that tight.

You’ll see in the “What’s next” section of the release notes that it’s a topic we are going to try to address, which means breaking changes to error codes. But we will do so in a “big bang” approach - clearly specifying the error codes that occur under which circumstances, and how client applications should react to them.

So in conclusion, they should be stable, but they are not because we didn’t specify them carefully enough for API 1.0.

3 Likes
4

Thanks Gary!

I didn’t notice it mentioned in the previous notes, I’ll be more thorough next time! Also thanks for the information @bernhard .

Regards,
Zoraiz

1 Like
5

We also attempted to set the build-options to force target 1.11, however, we still received the new error code.

1 Like
6

What option did you set exactly? The build-options entry can be used to set the Daml LF version (i.e. the version of the compiled bytecode emitted by the compiler), but I would not expect that to have any bearing here. To actually run an older version of Daml, you need to explicitly install and run that one. If you run Daml components through the daml assistant on the cli you can set the DAML_SDK_VERSION environment variable to specify a Daml version outside of a project, or set the sdk-version entry in your daml.yaml if you’re inside a project.

1 Like