Closed seolaoh closed 1 month ago
[!IMPORTANT]
Review Skipped
Auto reviews are disabled on base/target branches other than the default branch. Please add the base/target branch pattern to the list of additional branches to be reviewed in the settings.
Please check the settings in the CodeRabbit UI or the
.coderabbit.yaml
file in this repository. To trigger a single review, invoke the@coderabbitai review
command.You can disable this status message by setting the
reviews.review_status
tofalse
in the CodeRabbit configuration file.
[!TIP]
Early Access Features
- `gpt-4o` model for chat
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
Maybe we should add
insert
logic intryUnjail
, if we remove the validator when it is jailed.
Yeah I also thought about it, but I thought it defeats the purpose of the function to add insert
in the unjail
function. How about changing the subcommand to optionally do unjail
and activate
at once?
Maybe we should add insert logic in tryUnjail, if we remove the validator when it is jailed.
Yeah I also thought about it, but I thought it defeats the purpose of the function to add insert in the unjail function. How about changing the subcommand to optionally do unjail and activate at once?
I agree to separate insert
and unjail
because when a validator is jailed, the amount of delegation may be less than MIN_ACTIVATE_AMOUNT
due to undelegation. Maybe 2 step is required to re-activate validator from unjailed status.
Yeah I also thought about it, but I thought it defeats the purpose of the function to add
insert
in theunjail
function. How about changing the subcommand to optionally dounjail
andactivate
at once?
Could you elaborate it? I thought that if jail makes the validator to be removed from the tree, unjail should make it inserted in the tree.
I agree to separate insert and unjail because when a validator is jailed, the amount of delegation may be less than MIN_ACTIVATE_AMOUNT due to undelegation. Maybe 2 step is required to re-activate validator from unjailed status.
I think that can be handled by checking the current status of validator, and only insert to the tree if the status is ACTIVE
. I assume that may be cheaper than sending 2 transactions to unjail and activate the validator.
Yeah I also thought about it, but I thought it defeats the purpose of the function to add
insert
in theunjail
function. How about changing the subcommand to optionally dounjail
andactivate
at once?Could you elaborate it? I thought that if jail makes the validator to be removed from the tree, unjail should make it inserted in the tree.
I agree to separate insert and unjail because when a validator is jailed, the amount of delegation may be less than MIN_ACTIVATE_AMOUNT due to undelegation. Maybe 2 step is required to re-activate validator from unjailed status.
I think that can be handled by checking the current status of validator, and only insert to the tree if the status is
ACTIVE
. I assume that may be cheaper than sending 2 transactions to unjail and activate the validator.
I thought it's weird to add insert
in unjail
function, but I agree with your comment. I'll add it.
Description
Once validators have been sent to jail, they should not be sent to jail again before unjail, so changed to remove the validator from the validator tree when sending to jail.