Add schedule_as into TaskScheduled event

[imstar15]

Fixed the problem that when calling scheduleXcmpTaskThroughProxy, the who parameter of TaskScheduled was inconsistent with AccountId32 in automationTime.accountTasks in storage.

who is always the caller for extrinsic.

[chrisli30]

I’m not confident to check this in without unit tests. When you get time, please write down the design of unit test cases to make sure event filing for this xcmp task is right with a variety of inputs.

[imstar15]

The design of unit test case:

1. The proxy account Bob invokes scheduleXcmpTaskThroughProxy with scheduleAs: Alice.
2. In the emitted TaskScheduled event data, who should be Bob, and scheduleAs should be Alice.
3. In the ScheduledTasksV3 storage, it can be queried that the owner of this task is Bob.

@chrisli30

[chrisli30]

We need to include more tests around this function. For example,

1. schedule through an empty wallet address(empty string).
2. schedule through an invalid Turing wallet address.
3. schedule through a wallet address that is the same as the owner wallet.
4. schedule with an invalid multi-location
5. schedule with a non-existent multi-location
6. Could verify that the task can execute with a correct proxy?

[imstar15]

1. schedule through an empty wallet address(empty string).
The AccountId32::new(bytes) method requires a byte array parameter with 32 elements. An empty wallet address cannot be used to construct an AccountId32 variable.

let user_account = AccountId32::new([]);
    |                            ---------------- ^^ expected an array with a fixed size of 32 elements, found one with 0 elements
    |                            |
    |                            arguments to this function are incorrect
    |
    = note: expected array `[u8; 32]`
               found array `[_; 0]`

2. schedule through an invalid Turing wallet address.
The code within the automation time pallet does not perform validation checks on the account addresses.

Account address validation is a feature provided by the Substrate framework, which verifies the checksum of user addresses during actual runtime. I haven't verified this aspect yet.

However, in functional testing, incorrect account addresses will not result in an error.

schedule_as is a AccountId type parameter.

If you create an scheduleXcmpTaskThroughProxy extrinsic with polkadot.js API on Turing chain with other ss58 prefix address, polkadot.js API will convert it to a Turing address.

YFbVAJHJbn5sH523f3o6iLeropaD5CREtocrkPaGVzpJ5iz will be converted to 68TwNoCpyz1X3ygMi9WtUAaCb8Q6jWAMvAHfAByRZqMFEtJG

If the conversion fails, an error will be thrown:

Struct: failed on schedule_as: AccountId:: Decoding YFbVAJHJbn5sH523f3o6iLeropaD5CREtocrkPaGVzpJ222: Invalid decoded address checksum.

4. schedule with an invalid multi-location
5. schedule with a non-existent multi-location

The automation time pallet does not check on whether destination parameter is a valid MultiLocation, as that responsibility lies within the XCM module.

Alternatively, end-to-end (E2E) tests can be done to verify it.

The automation-time pallet does not check xcm_asset_location parameter.
Because the calculation logic of XCM instruction fee is in the xcmp-handler pallet.
In the mock implementation, we do not provide real functionality.

https://github.com/OAK-Foundation/OAK-blockchain/blob/67b4f7f5976d58dd35b080cf325eb01dff4921a7/pallets/automation-time/src/mock.rs#L285C33-L285C47

6. Could verify that the task can execute with a correct proxy?
The MockEnsureProxy is only used for automation-time testing purposes. However, it is not a fully functional proxy module in a real sense.

https://github.com/OAK-Foundation/OAK-blockchain/blob/e8415385756db9daf29cf12cb2ae49e2772d4c7d/pallets/automation-time/src/mock.rs#L352

[chrisli30]

5. a wrong xcm_asset_location for destination doesn’t cause error on our XcmMessageSent, but causing one on relay chain instead. Therefore, we can’t test the validity in our chain’s code.

[chrisli30]

Looks good to me!