-
Notifications
You must be signed in to change notification settings - Fork 0
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
Subscription SC #2
Conversation
Contract comparison - from fcaab6f to 3ec44bf
|
tokens_to_withdraw.to_vec() | ||
}; | ||
|
||
let user_fees_mapper = self.user_deposited_fees(caller_id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mate 2 endpoints, withdrawFund and withdrawFees
subscriber/src/daily_operations.rs
Outdated
fees_contract_address.clone(), | ||
); | ||
if subtract_result.is_err() { | ||
return CONTINUE_OP; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if this is an error - the whole execution will fail anyway. No need for this check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, this is a custom error. If I made it that way, the contract would get stuck if a user didn't deposit tokens for fees.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but if the ExecuteOnDestContext fails - the whole contract will fail anyway. So it does not matter if it is a custom error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, it's just an error, but not a VM panic. It simply says "hey, this didn't work".
subscriber/src/daily_operations.rs
Outdated
&service_info, | ||
user_data.borrow(), | ||
); | ||
if action_results.is_err() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if this is an error - the whole execution will fail anyway. No need for this check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but if the ExecuteOnDestContext fails - the whole contract will fail anyway. So it does not matter if it is a custom error.
MyVeryOwnScResult::Err(_) => unreachable_unchecked(), | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be better to use addresses instead of IDs for arguments on endpoints. For external integrations is easier to work directly with address instead of ID
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is cheaper for the bot. to have IDs.
subscription-fee/src/fees.rs
Outdated
} | ||
|
||
let mut opt_found_token_index = None; | ||
for (index, user_token) in all_user_tokens.iter().enumerate() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we remove this for
by using a storage?
MyVeryOwnScResult::Err(_) => unreachable_unchecked(), | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is cheaper for the bot. to have IDs.
service_info: &ServiceInfo<<Self::SubSc as ContractBase>::Api>, | ||
additional_data: &<Self as SubscriberContract>::AdditionalDataType, | ||
) -> Result<InterpretedResult<<Self::SubSc as ContractBase>::Api>, ()> { | ||
let rewards_vec = sc.claim_metaboding_rewards( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we actually want boosted-rewards-subscriber - not metabonding. Where we claim boosted rewards from a set of farm/metastaking and feescollector addresses for that user.
Metabonding can stay, but we need a new contract where perform action will call claimBoostedRewards
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only an example, it's a lot easier to integrate something like metabonding for testing purposes.
|
||
let mut services = ManagedVec::<Self::Api, _>::new(); | ||
for arg in args { | ||
let (sc_address, energy_threshold, payment_type) = arg.into_tuple(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No energy threshold in this contract. This contract does not know about energy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still missing feature of registering multiple services from the same address.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Periodicity has to be saved here, and only allow to take_payment once per periodicity.
#[endpoint(registerService)] | ||
fn register_service( | ||
&self, | ||
args: MultiValueEncoded<MultiValue3<ManagedAddress, BigUint, PaymentType<Self::Api>>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
arguments are not energy_threshold. But payment and periodicity.
let opt_user_address = self.user_id().get_address(user_id); | ||
let user_address = opt_user_address?; | ||
let user_energy = self.get_energy_amount(&user_address); | ||
let cost = if user_energy >= service_info.energy_threshold { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no energy threshold here.
#[endpoint(subtractPayment)] | ||
fn subtract_payment( | ||
&self, | ||
service_index: usize, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so the caller can have multiple serviceIDs. Check if user is subscriber for that service ID and check the periodicity. Like when was the last time payment was subsctracted.
output_esdt.push(payment); | ||
} | ||
|
||
let action_results = SC::perform_action( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually we do several actions per one user per one payment. Like we claim boosted rewards for all his farms and fees collector.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each subscriber contract can do whatever they want in their perform_action
implementation. If they want to perform several actions for one payment, that's fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments will be resolved in next PR.
The current PR contains 3 contracts: