Non deterministic generation of binaries

[bdemann]

UPDATE

This issue is related to a bug in dfx. When it gets fixed we can verify and close out this issue

• update dfx
• verify fix
• remove both of the multi_deploy examples from the Unstable Tests

Bug Report: Azle seems to generate binaries non-deterministically

Description

If you deploy twice in a row without changing the code sometimes it will treat the second deploy as a no change and do nothing, and sometimes it will treat it as a second deploy and run postupgrade.

Steps to Reproduce

1. Create canister with someway to see if init and post upgrade gets run
2. Deploy the canister
3. Verify that init was called
4. Deploy again

Expected Behavior

On the second deploy neither the init nor the post upgrade methods should have been called, because the deploy should have been skipped.

Actual Behavior

Sometimes the deploy happens and post upgrade method is called.

[bdemann]

I have started working on a new test to make sure this doesn't happen in the future and hopefully it will help us troubleshoot the currently problem.

basically it builds the wasm binary several times in a row and makes sure that the hash is the same every time. Then we go ahead and deploy the canister and make sure that the init and postUpgrade methods are called as we expect.

[bdemann]

For more information checkout this thread

https://forum.dfinity.org/t/discrepancy-between-local-sha-256-wasm-hash-and-canister-statuss-module-hash/25145/9

But basically dfx deploy adds some meta data to the binary, Amoung that meta data is icp:public dfx which looks like this

$ ic-wasm .dfx/local/canisters/canister/canister.wasm metadata dfx
{
  "tech_stack": {
    "cdk": {
      "azle": {}
    },
    "language": {
      "javascript": {},
      "typescript": {}
    }
  }
}

And the problem is that sometimes it will flip the order of javascript and typescript resulting in the module hash being different.

That means it's a dfx bug and we are good to go.

I have added some multi_deploy tests which should help us verify that this issue is resolved when it gets resolved.

Those examples will be added as part of this pr #2143