Breaking change for V0.6.8

Edit:

Hi all,

There were some compatibility issues with the SDK and the Tungsten network this release. Therefore we have rollback’d the network. Until the next release, please continue to use DFX 0.6.7 when developing on Tungsten.

We’ll keep you posted on more changes.

Thanks,
Prithvi

Original Message:

Hi all,

We completed a breaking release to Tungsten earlier today.
This release has some internal changes which require all onboarded devs to install and use 0.6.8 of the SDK.
Developers not onboarded to Tungsten will not have any impact.

Please feel free to reach out to the team if you have questions or run into any issues.

Thanks!

2 Likes

Hey Prithvi, just upgraded and getting some errors:

Build failed. Reason:
  Build step failed for canister cxeji-wacaa-aaaaa-aaaaa-aaaaa-aaaaa-aaaaa-q with error: Build failed. Reason:
  Command "/Users/nw/.cache/dfinity/versions/0.6.8/moc" "/Users/nw/work/sailfish/src/backend/actors/SampleToken.mo" "-o" "/Users/nw/work/sailfish/.dfx/local/canisters/SampleToken/SampleToken.wasm" "-c" "--debug" "--actor-idl" "/Users/nw/work/sailfish/.dfx/local/canisters/idl/" "--actor-alias" "SampleToken" "cxeji-wacaa-aaaaa-aaaaa-aaaaa-aaaaa-aaaaa-q" "--package" "base" "/Users/nw/.cache/dfinity/versions/0.6.8/base"
 returned an error:
Fatal error: exception Codegen.Compile.CodegenError("Local actors not supported by backend")
Raised at file "codegen/compile.ml", line 47, characters 42-64

pinging @claudio

@prithvi I am onboarded to the tungsten network and executing dfx upgrade still leaves me on 0.6.7
Also fresh install does not help.

1 Like

@klauss.johannes you will need to use this format to install an unreleased version: DFX_VERSION=0.6.8 sh -ci "$(curl -fsSL https://sdk.dfinity.org/install.sh)"

3 Likes

Thank you, that got me working again.
But something very weird happened with my canisters on the tungsten network.
If I want to reinstall them, I get the error message, that my canisters are not found.
But if I try to create them, it states that they already exist.

Deleting the canister didn’t help either.

I got it working again by deleting my .dfx folder. Thanks for the fast help :slight_smile:

2 Likes

Hey Norton, I see you pinged Claudio. I relayed this to the Motoko team as well.

Norton, are you good again? Or are you still seeing the strange failure from Motoko?

Norton, is this still an issue? Would you be able to share the code (or a small repro) causing this?

I managed to repro with this:

class A() {};
actor B {};

Ah, there’s a breaking change in Motoko that an actor has to be the only declaration following imports in a program. The compiler should not crash. though, but just report an error.

You would need to restructure this program to put the class in a library that is imported.

lib.mo

class A() {};

main.mo

import L "lib";
actor B { 
     … L.A() ...
}

Should compile sans error.

Do you have a lot of code where the main actor is preceded by some local declarations?

1 Like

Ah yeah that does it. I have a few places where I declare local types and functions, easy fix. Thanks!

Btw, any idea when we’ll be able to import actors? Would be nice to have unit tests on my actors instead of just dfx/js tests.

Well, you can import a canister reference already, if your project has multiple canisters.

Undocumented feature: you can also import an actor class (not an actor), as a library. Calling the constructor does a programmatic canister install. But I’m about to change that slightly so it gets imported as a module containing an actor class to preserve the invariant that all imports are modules.

That’s part of the reason your code broke.

Oh yes, I should have mentioned that pulling the leading declarations into the actor is another fix (and probably more convenient). One gotcha: type declarations will have to be made public if they appear in the actor’s interface.

ie. in your example:

actor B { 
     class A() {};
     … A() ...
}

should work.

Got a different issue now when installing canister:

Sep 17 00:24:18.134 WARN s:fscpm-uiaaa-aaaaa-aaaap-yai/n:5wjwg-gteaa-aaaaa-aaaap-2ai/ic_execution_environment/canister_manager install_canister failed: CalledTrap("RTS error: object_size: invalid object tag")

Any idea what that could be? The actor compiles just fine.

edit: I managed to repro:

import Nat "mo:base/Nat";

actor B {
  var x = Nat.pow(2, 30);

  func b() {
    ignore x
  }
}

This breaks when x >= 2**30 for types Nat and Int. Other numeric types work as expected.

edit2: This also happens when x is set dynamically:

actor B {
  var x = 0;

  public func b(x_: Nat) {
    x := x_
  }
}

Found a bug with @dfinity/agent@0.6.8: the requestStatus method on HttpAgent is missing the new ingress_expiry field.

ping @hansl

1 Like

The compiler crash reported by @wang is fixed and should be available in the next release of dfx.

1 Like

Just to close the loop here, we have several known bugs in 0.6.8 that only impact devs onboarded to Tungsten, as 0.6.8 has not been publicly released yet is currently required to access the updated Tungsten network. We will be releasing 0.6.9 early next week to fix these bugs, but in the meantime, you may not be able to deploy your canisters to Tungsten. Apologies for any convenience and we will have you back up and running soon!

1 Like

Hi @wang,

The object_size: invalid object tag error is now fixed in master and the fix should be released with the next dfx.

2 Likes

Hi all,

There were some compatibility issues with the SDK and the Tungsten network this release. Therefore we have rollback’d the network. Until the next release, please continue to use DFX 0.6.7 when developing on Tungsten.

We’ll keep you posted on more changes.

Thanks,
Prithvi