Move scripts

I met a trouble when I tried to run a script include a function in DiemTimestamp, details are shown below:

Execution aborted with code 257 in module 00000000000000000000000000000001::DiemTimestamp. Abort code details:
Description: The blockchain is not in an operating state yet
Description: The system is in a state where the performed operation is not allowed. Example: call to a function only allowed
in genesis.

and my function is :
public fun myfun(n1: u64, n2:u64):(){
let now = DiemTimestamp::now_microseconds(); //timestamp included
if (now % 15 == 0) {
} else {

This seems to be because the blockchain is still in the genesis state. How can I change it to the an operating state?

Hope for your reply , thanks!

Hello @Diemer !
If you are running this in an environment such as move-executor, this is expected, since the full blockchain is not running (personally I have an “if” statement which uses a constant timestamp if in the genesis state).

I guess you should be still able to deploy it on your own network?

Hello @villesundell !
I think you are right, and I was wondering if there is a way to run such a script in a move environment (without/with linking to the testnet or a localnet)?
In addition, it does not appear that the complie and publish command line code is currently available in the test network environment.I also had problems running the release of the Move module on my local network.The error message is’ SENDING_ACCOUNT_DOES_NOT_EXIST ', even though I have created the account beforehand.I feel this problem is similar to [ How to compile/publish modules using Diem CLI client connected to a local test validator network?], but I still can’t find a solution.

Thanks for your reply !

A lot to unpack there :slightly_smiling_face:

  1. Well, I would propose similar if statement I have here.

  2. Yep, the testnet does not accept third party modules at the moment (meaning us, since we are not part of the Diem Association :laughing: )

  3. Did you check that the account is indeed there? Did you try to query its state/balance? Please note, that if you restart your local network (by default) you lose your chain state (meaning accounts, etc.), and everything is created from scratch once you restart your network.

@Diemer: if you are ok with running against an on-disk state rather than testnet, the Move CLI might be a good fit. Here’s an example test that runs Diem genesis locally and then does a few test transactions. You should be able to run your script if you follow a similar setup process.

@sam Thank you very much!
I ran the CLI and got an error message blow:

Updating git repository ``

error: failed to parse manifest at /home/ubuntu/.cargo/git/checkouts/diem-3157fea0403687f7/ba0806d/Cargo.toml

Caused by:
feature resolver is required

consider adding cargo-features = ["resolver"] to the manifest

Then I ran the script in the previous Move version (bcs = ‘0.1.1’; anyhow = “1.0.34”) and I got a message blow:
Execution failed with unexpected error CONSTRAINT_NOT_SATISFIED

:joy:Did I miss something?

Did you run the CLI install command cargo install --git move-cli --branch main inside your clone of the Diem repo?

Yes, I ran the CLI install command cargo install --git move-cli --branch main and then I got the error message blow:

Updating git repository ``

error: failed to parse manifest at /home/ubuntu/.cargo/git/checkouts/diem-3157fea0403687f7/ba0806d/Cargo.toml

Caused by:
feature resolver is required

consider adding cargo-features = ["resolver"] to the manifest

Besides, I ran the CLI $ cargo install --path diem/language/tools/move-cli after I git diem and I got the same error message.
And then I tried to modify the mainfest and failed

Spoke with some our Rust experts and they mentioned that the resolver error can result from an older version of cargo (see this for more details). You might try rustup update to get the latest cargo and see if that fixes your problem.

Thank you very much! The problem was fixed after “rustup update”. I try the Move CLI and found some problems:

  1. I can not see the coverage information after I use the “–track-cov” at the end of “move test readme”;
  2. Is the “account” should be “&account” in the 4th line " Debug::print(account)" of the script “debug_script.move” and “has key” in the " struct Resource { i: u64 } has key" of the “Test.move” should be front of “{}” ?

Thank you again !

@villesundell Thank you very much ! I’ve learned a lot from your code! But I still don’t understand how to get the value of the resource outside the module. For example, maybe I can get the resource DiemVersion use
let v = DiemConfig::get<0x1::DiemVersion::DiemVersion>();

However I can not get the value of DiemVersion.major Since there is no get() function in the module DiemVersion .

I’ve tried a few things, but I often get an error message like this:
“Invalid access of field ‘major’ on ‘0x1::DiemVersion::DiemVersion’. Fields can only be accessed inside the struct’s module”

CC @mengxu-fb and @tzakian for the track-cov question.

Hi @Diemer,

I am able to produce the coverage info on my local setting so my guess is that some error, most likely compilation error. happened and the move test did not even get a chance to run and measure the coverage. Maybe the compilation error is related to your second point:

  1. for the two scripts in src/scripts, they should take a account: signer as argument of the main function and subsequently be converted to &account when passed to Debug::print or Test::publish. The complete code should look like:
cat src/scripts/debug_script.move
script {
use 0x1::Debug;
fun main(account: signer) {

cat src/scripts/test_script.move
script {
use 0x2::Test;
fun main(account: signer) {
  1. The resource declaration in modules/Test.move should look like
struct Resource has key { i: u64 }

Once these are fixed and everything compiles and runs, you should be able to see the coverage results as shown in the readme tutorial.

1 Like

Thank you very much !
I run the scripts of the diem_smoke in move-cli and met a problem:
When I run the second cli in the args.txt manually – (
sandbox run scripts/create_designated_dealer.move --mode diem --type-args 0x1::XDX::XDX --signers 0xB1E55ED --args 0 0xDD x"00000000000000000000000000000000" b"DD" true -v),
I got an error as follows:

diem@ubuntu:~/diem0615/diem-main/language/tools/move-cli/tests/testsuite/diem_smoke$ move sandbox run scripts/create_designated_dealer.move --mode diem --type-args 0x1::XDX::XDX --signers 0xB1E55ED --args 0 0xDD x"00000000000000000000000000000000" b"DD" true -v
error: Invalid value for ‘–args …’: unexpected token Name(“x00000000000000000000000000000000”), expected transaction argument

BUT, when I run the whole test use “move sandbox test”, I got none error:

diem@ubuntu:~/diem0615/diem-main/language/tools/move-cli/tests/testsuite$ move sandbox test diem_smoke
1 / 1 test(s) passed.

The quote symbol (") needs to be properly escaped as bash or shell commands. So when you are manually typing them in the terminal, try to escape the " with ":

In the case of the second command, it is:
move sandbox run scripts/create_designated_dealer.move --mode diem --type-args 0x1::XDX::XDX --signers 0xB1E55ED --args 0 0xDD x\"00000000000000000000000000000000\" b\"DD\" true -v

Thank you very much! It works for me.
And may I ask you another question? I found a lot of meaningless data on the testnet( with a Block Metadata TX Type.What do these data mean and how does it come about ?

Disclaimer: I am not an expert on the Diem transaction types nor the testnet, so it is purely based on my personal reading of the code here: diem/ at main · diem/diem · GitHub

The BlockMetadata type is the transaction type that updates the block metadata resource at the beginning of a block. What is actually stored in the block metadata can be found here: diem/ at main · diem/diem · GitHub