PackageId hash changes without Daml code change

We bumped into an issue of packageId hash changes non-deterministically when we did not change any daml codes (no changes to daml.yaml file and no changes to any .daml file)

1 Like

We later on figured out that this is because we have the -j flag on when doing daml build

daml build -j 

As specified by the docs

The number of threads to run in parallel. 
When -j is not passed, 1 thread is used. 
If -j is passed, the number of threads defaults to the number of number of threads to N. 
Note that the output is not deterministic for > 1 job.

Important and painful takeaway for me: packageId only remains the same if we have -j = 1 (or simply don’t add the flag in, default -j is 1) and there’s no changes in .daml files and daml.yaml file.
Hope this will help anyone that is scratching their head over the same issue.

2 Likes

Interesting find, thanks for posting the solution!

I would also recommend including package ID extraction as part of the build process. For example, the create-daml-app and quickstart-java we supply work like this:

  1. build daml dars
  2. generate TypeScript/Java code from the dars, including package ID
  3. compile hand-written TypeScript/Java code against that generated code, hence using the package ID that was just built

For cross-project dependencies, data-dependencies are the best choice to preserve package ID stability.

Only adding this to say that there is a range of solutions to this issue, and different projects will find different ones to be appropriate.

2 Likes

Hi @Stephen,

Could you elaborate a bit on what guarantees data-dependencies offer compared to dependencies?

Thanks

1 Like

The “cut the Gordian knot” way to preserve package ID is to use a distributed prebuilt binary. Can’t get multiple package IDs if you’re always using exactly one prebuilt package, after all.

data-dependencies fix

  1. the SDK upgrade problem with this strategy – you can use deps built with older SDK versions in new projects
  2. the distribution problem – you don’t need an out-of-band dar distribution mechanism to fetch a data-dependency, you can use the ledger
  3. relatedly, the “lost library” problem – if upstream loses or has trouble reproducing a dar, it doesn’t matter, because if the templates/data types are in use, the correct dalfs must be on a relevant ledger
1 Like