Failed to rooch move run

[wubuku]

Here is the demo example:

https://github.com/wubuku/rooch/tree/main_add_a_example/examples/basic_object_example/sources

First run a local server, and publish:

rooch move publish -p ../../examples/basic_object_example/ --sender-account 0x123

Run this command line, but failed:

rooch move run --function 0x123::something_aggregate::create_something --args 1 2 --sender-account 0x123

Server side output info.:

[VM] failed to deserialize argument
VMError with status FAILED_TO_DESERIALIZE_ARGUMENT at location UNDEFINED

[baichuan3]

Type args parse is not fully implemented yet, right? Needs to be defined as type:value, for example u32:100 address:0x1234? @pause125

https://github.com/rooch-network/rooch/blob/85e317b006201eaae96e68b6c4c82ae92f6524a2/moveos/moveos-cli/src/commands/run_function.rs#L98-L106

[pause125]

For now, only basic types are supported.

@wubuku You shoud indicate the argment type like this:

rooch move run --function 0x123::something_aggregate::create_something --args 1u32 2u128 --sender-account 0x123

[wubuku]

Yes, the following command will succeed on the first execution:

rooch move run --function 0x123::something_aggregate::create_something --args 1u32 2u128 --sender-account 0x123

The next issue is how to obtain information about the newly created object through CLI.

Note that I am using Box Style Objects, so it is not possible to query resources under the account by:

rooch resource --address 0x123 --resource 0x123::something::SomethingProperties

The ObjectID is not a user-assigned ID, but rather a surrogate ID generated by the network, and even the Rooch Server Side output does not currently provide information about ObjectID generation.

Therefore, the following command is unusable (and it is unclear what the results of running this command would be):

rooch object --id XXXXXXXXX

---

There is actually another issue, which is that this command can only be successfully executed once:

rooch move run --function 0x123::something_aggregate::create_something --args 1u32 2u128 --sender-account 0x123

When the second execution fails, the error message output by the Server Side is:

VMError with status ABORTED with sub status 25607 at location Module ModuleId { address: 0000000000000000000000000000000000000000000000000000000000000001, name: Identifier("raw_table") } at code offset 0 in function definition 1

I think the second execution shouldn't fail, and should be able to create another object with a new ObjectID. Right?

@pause125 @baichuan3

[wubuku]

Regarding how to get ObjectID, if I were developing an application, I would prefer to generate a corresponding "XxxxObjectCreated" DOMAIN events, regardless of whether the network's stdlib/framework provides lower-level Object-Created events. Then, the off-chain service can capture this event and store the ObjectID in the off-chain database.

---

Additionally, Sui provides an interface to query objects that are owned by a certain address:

https://docs.sui.io/sui-jsonrpc#suix_getOwnedObjects

However, if I were developing an application, I would not rely solely on querying this interface to retrieve the objects' information that the application cares about, if possible.

[baichuan3]

Yes, the following command will succeed on the first execution:

rooch move run --function 0x123::something_aggregate::create_something --args 1u32 2u128 --sender-account 0x123

The next issue is how to obtain information about the newly created object through CLI.

Note that I am using Box Style Objects, so it is not possible to query resources under the account by:

rooch resource --address 0x123 --resource 0x123::something::SomethingProperties

The ObjectID is not a user-assigned ID, but rather a surrogate ID generated by the network, and even the Rooch Server Side output does not currently provide information about ObjectID generation.

Therefore, the following command is unusable (and it is unclear what the results of running this command would be):

rooch object --id XXXXXXXXX

There is actually another issue, which is that this command can only be successfully executed once:

rooch move run --function 0x123::something_aggregate::create_something --args 1u32 2u128 --sender-account 0x123

When the second execution fails, the error message output by the Server Side is:

VMError with status ABORTED with sub status 25607 at location Module ModuleId { address: 0000000000000000000000000000000000000000000000000000000000000001, name: Identifier("raw_table") } at code offset 0 in function definition 1

I think the second execution shouldn't fail, and should be able to create another object with a new ObjectID. Right?

@pause125 @baichuan3

Multiple execution failures are caused by repeated object_id generated during repeated transaction execution.

The reason is that when object::new obtains object_id, it calls tx_context::fresh_address, tx_context will be newly created in each transaction execution, resulting in ids_created always being 0, and when the same transaction is executed multiple times, tx_hash is also the same, the result The object_id generated each time is the same.

The solution is to move the TxContext to the user's resource, and the vm will fill in ids_created from the Resource when creating the TxContext each time the vm executes a transaction. @jolestar

In addition, the Ocject information is finally output through the event, and the event has not been realized yet, so the log output is added first, so that the process can be connected through the cli.

[jolestar]

the tx_hash is not changed because we do not put the sequencer_number in the tx. I will resolve this in the next PR.

[wubuku]

Maybe a little bit off topic:

Sui has removed the sequence number, but every time Sui sends a transaction, it needs to pass in the Gas object used. Because objects have versions, different transactions should not generate duplicate hashes.

[jolestar]

version == sequencer_number.

try this #135

[jolestar]

relative issue #209

[jolestar]

This issue is resolved.