Ledger API Error Code Backwards Compatibility

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
  - Alice
  - Bob
  - Charlie
  - David
version: 0.0.2
  - daml-prim
  - daml-stdlib
    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.


1 Like

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.


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.


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 .


1 Like