@Jovells I just realised that claiming ment can only be. done when the contract is paused
@mickeymond Yes because there's that checkpoint that needs to be set based on block number and you cannot have people voting at the same block number when the mentor is claiming some of their votes as MENT.
@Jovells Oh okay. So how the user flow be like ? How will the mentor know when the contract has been posted for him to claim?
@mickeymond There is a view function on the emt marketplace called paused() which returns a boolean to either show the claim ment button or display a message that mentor cannot claim their ment at the moment.
On the other side, voting is not allowed when the contract is paused as well so that will mean the conditional display of upvote and downvote or a message that voting is on hold for now.
Of cos there will have to be communication to the community whenever this actions are taken.
@Jovells Oh okay I think technically that should work. I'm just wondering how convenient that will be for users.
Especially the fact that voting and claiming cannot happen simultaneously.
@mickeymond That is the current limitation we have with claiming ment.
I checkpoint needs to be taken to know when lastly a mentor claimed their ment so to prevent earlier voters from changing their votes and newer votes to count in the next claim.
Right now it is based on block number and we cannot have a claim action and a voting action happening in the same block
One needs to be greater or lesser than the other.
Equal seems futal to me when I went over it in my head.
@Jovells Oh okay. I get it
Does this mean that, on the blackchain, transactions which happen in the same block and interact with the same data will encounter concurrency issues?
@mickeymond No that is not what will happen at all.
It will go through just fine.
The bug that will be introduced on our end it that, if mentor claimed at block number 30 and a voter voted at the same block number 30, that votes will end up getting neglected
@Jovells Oh okay..how about making it such that votes in the same block as a claim will count towards the next claim
So if you try to change your vote and the mentor happens to have claimed in the same block, it won't go through
@mickeymond After going through the code again, it is clear to me that pausing the contract has very little to do with the mentor claiming the right amount and everything to do with allowing a previous voter to change their vote based on the block number at which the mentor made their last claim.
If your vote was cast at block number 29.
And the mentor claimed at block number 30, then you cannot change your vote again.
@Jovells Okay. So the pausing won't be necessary?
@mickeymond After we settle on whether on not to allow a voter to change their vote if they voted at block number 30 and the mentor claimed at block number 30.
Because their vote may have been claimed.
@Jovells If the vote was done before the claim , it would have been claimed. If it was done afterward, It would not have been claimed.
But in both cases, the block number would be 30.
So if we allow votes in the same block as claims to be changed, It undermines the claiming system
If we do not, it prevents some unclaimed votes from being changed.
Interesting.
In my opinion, we can go with preventing changing of votes in the same block as claims because
The probability of that happening is low
Even if it happens, the cost in terms of user experience is much less than having to pause the contract for claims to happen
@mickeymond Noted but we will have to settle on this with the rest of the team.
Do I need to PAUSE & UNPAUSE the current version deployed to TOPOs for you to continue for DEV work?
@Jovells I just realised that claiming ment can only be. done when the contract is paused
@mickeymond Yes because there's that checkpoint that needs to be set based on block number and you cannot have people voting at the same block number when the mentor is claiming some of their votes as MENT.
@Jovells Oh okay. So how the user flow be like ? How will the mentor know when the contract has been posted for him to claim?
@mickeymond There is a view function on the emt marketplace called paused() which returns a boolean to either show the claim ment button or display a message that mentor cannot claim their ment at the moment. On the other side, voting is not allowed when the contract is paused as well so that will mean the conditional display of upvote and downvote or a message that voting is on hold for now. Of cos there will have to be communication to the community whenever this actions are taken.
@Jovells Oh okay I think technically that should work. I'm just wondering how convenient that will be for users. Especially the fact that voting and claiming cannot happen simultaneously.
@mickeymond That is the current limitation we have with claiming ment. I checkpoint needs to be taken to know when lastly a mentor claimed their ment so to prevent earlier voters from changing their votes and newer votes to count in the next claim. Right now it is based on block number and we cannot have a claim action and a voting action happening in the same block One needs to be greater or lesser than the other. Equal seems futal to me when I went over it in my head.
@Jovells Oh okay. I get it Does this mean that, on the blackchain, transactions which happen in the same block and interact with the same data will encounter concurrency issues?
@mickeymond No that is not what will happen at all. It will go through just fine. The bug that will be introduced on our end it that, if mentor claimed at block number 30 and a voter voted at the same block number 30, that votes will end up getting neglected
@Jovells Oh okay..how about making it such that votes in the same block as a claim will count towards the next claim So if you try to change your vote and the mentor happens to have claimed in the same block, it won't go through
@mickeymond After going through the code again, it is clear to me that pausing the contract has very little to do with the mentor claiming the right amount and everything to do with allowing a previous voter to change their vote based on the block number at which the mentor made their last claim. If your vote was cast at block number 29. And the mentor claimed at block number 30, then you cannot change your vote again.
@Jovells Okay. So the pausing won't be necessary?
@mickeymond After we settle on whether on not to allow a voter to change their vote if they voted at block number 30 and the mentor claimed at block number 30. Because their vote may have been claimed.
@Jovells If the vote was done before the claim , it would have been claimed. If it was done afterward, It would not have been claimed. But in both cases, the block number would be 30. So if we allow votes in the same block as claims to be changed, It undermines the claiming system If we do not, it prevents some unclaimed votes from being changed. Interesting. In my opinion, we can go with preventing changing of votes in the same block as claims because
@mickeymond Noted but we will have to settle on this with the rest of the team. Do I need to PAUSE & UNPAUSE the current version deployed to TOPOs for you to continue for DEV work?