Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: MMD-1309 10-to-1 - Off-chain workers #238

Draft
wants to merge 37 commits into
base: luke/rewards-allowance-new
Choose a base branch
from

Conversation

ltfschoen
Copy link
Collaborator

@ltfschoen ltfschoen commented Nov 6, 2021

  • - i asked this question in room "Builders Program - Chains Track" in Element on 10th Nov 2021:
    i added the offchain_worker function and some new off-chain workers logic to a pallet where i had already setup other logic and had the mock configured so unit tests were passing.

i had it working in mock.rs with type AccountId = u128

impl frame_system::Config for Test {
    ...
    type AccountId = AccountId;
...

but now i have to update mock.rs so it works with off-chain workers, but i'm not sure how to get it to work.

in frame example-offchain-workers AccountId is:

impl frame_system::Config for Test {
        ...
	type AccountId = sp_core::sr25519::Public;
...

(as shown here: https://github.com/paritytech/substrate/blob/master/frame/example-offchain-worker/src/tests.rs#L67
)

where AccountId is:

type AccountId = <<Signature as Verify>::Signer as IdentifyAccount>::AccountId;

(as shown here: https://github.com/paritytech/substrate/blob/master/frame/example-offchain-worker/src/tests.rs#L83)

and it uses <Signature as Verify>::Signer in these two places:

so far the changes i've made are in this PR in the file pallets/mining/rewards-allowance/src/mock.rs here: https://github.com/DataHighway-DHX/node/pull/238/files#diff-b7ace9b0e8a1d800ea987e0e9b9e117f8fe6a52b923a9e654b65495c90c7ffd5R468

and when i run the tests with cargo test -p mining-rewards-allowance, i get the following error:

error[E0271]: type mismatch resolving `<sp_core::sr25519::Public as IdentifyAccount>::AccountId == u128`
   --> pallets/mining/rewards-allowance/src/mock.rs:449:2
    |
449 |     type Public = <Signature as Verify>::Signer;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u128`, found struct `sp_core::sr25519::Public`
    |
note: required by a bound in `frame_system::offchain::SigningTypes::Public`
   --> /Users/ls2/.cargo/git/checkouts/substrate-f10629da2328b525/f5dc02a/frame/system/src/offchain.rs:453:21
    |
453 |         + IdentifyAccount<AccountId = Self::AccountId>
    |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `frame_system::offchain::SigningTypes::Public`

SOLUTION: This was fixed in this commit 9ad33cd

  • - need to move all on_initialize code into offchain_worker function, and need to figure out what date to use for storing data (i.e. in function set_mpower_of_account_for_date we're storing a next_start_date, but in offchain_workers we might be storing the current date for MPowerForAccountForDate...
    i.e. if there are a lot of registered miners and it takes more than a day to receive and process all of the offchain data received and we're storing that under a key of the current day it's being processed on on-chain, then if we don't finish going through all those registered miners in one day then they might be stored under a key for tomorrow's date incorrectly....

so instead we should be providing the date that the account id's mpower relates to from the API with a timestamp, and then in offchain_workers figure out the start of that date, and store it.

Note: See Jira mPower MMD-1584 for latest status

ltfschoen and others added 17 commits November 8, 2021 12:00
Co-authored-by: Xiliang Chen <xlchen1291@gmail.com>
resolved errors that i was getting in the logsoffchain_workers error fetching mpower  and offchain_workers error unknown transaction type  , which appears to because i needed to change the GRACE_PERIOD to a shorter period of say 10 seconds instead of 1 minute

i also only had a single account Alice in the chain_spec as a value for cooling_off_period_days_remaining, but I also needed Bob since, and because in the hard-coded mpower data response from the API i had two accounts with an mpower value, but they accidently both had Alice’s public key hex, so it was using the same account when iterating over multiple miners.

i also wasn’t providing the correct value for the account id to the function set_mpower_of_account_for_date (i was providing the unsigned account id instead of the account id property i’d added as mpower_data_item.account_id_registered_dhx_miner

i checked that i could successfully check on-chain storage for MPowerForAccountForDate` by providing the start of a current date that had been stored, and the public key (hex) value that was provided for the account id in the API response (even though we’re storing the key as Vec<u8> it still fetches it correctly in the UI

change to store accounts as public keys Vec<u8> instead of AccountId
@ltfschoen ltfschoen force-pushed the luke/rewards-allowance-new-offchain branch from fa7a464 to 18f919a Compare December 2, 2021 07:12
return Err(DispatchError::Other("Unable to multiply to determine challenge_period_millis"));
}

let challenge_period_millis = challenge_period_days.clone() * millis_per_day.clone();
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this a duplicate? we're already using checked_mul a few lines before

println!("existing challenge_period_days: {:?}", challenge_period_days.clone());
} else {
log::error!("Unable to get challenge_period_days");
return Err(DispatchError::Other("Unable to get challenge_period_days"));;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove double ;; as only single necessary

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants