-
Notifications
You must be signed in to change notification settings - Fork 2
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
chore(e2e): e2e test for activating and unbonded in mempool #71
Conversation
// In this test, we include both staking tx and unbonding tx in the same block. | ||
// The delegation goes through "VERIFIED" → "ACTIVE" → "UNBONDED" status throughout this test. | ||
func TestActivatingAndUnbondingDelegation(t *testing.T) { | ||
//t.Parallel() |
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.
for some reason, there might be an unwanted dependancy between e2e test, making it sequential until, will investigate (related to btc frequent headers maybe)
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.
"works on my machine" type of thing 😅
// we should track both verified and active status for unbonding | ||
if sew.unbondingTracker.GetDelegation(delegation.StakingTx.TxHash()) == nil { | ||
changed, exists := sew.unbondingTracker.HasDelegationChanged(delegation.StakingTx.TxHash(), del) |
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.
the delegation might have changed from verified to active status, in order to track unbonding, we need the activation height, and data in the tracker might be stale, so let's check this
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 was a bit confusing the checks exists && changed
or !exists
If the delegation didn't exists, we still push it as a new delegation to the unbondingDelegationChan
?
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.
Yes, we want to track it, but we also want to push it to the channel if it exits and has changed (e.g went from verified -> activated)
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.
LGTM then ^^
|
||
// Compare fields to check if the delegation has changed | ||
if existingDelegation.StakingOutputIdx != newDelegation.stakingOutputIdx || | ||
!reflect.DeepEqual(existingDelegation.UnbondingOutput, newDelegation.unbondingOutput) || |
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.
hmm I think the only thing that could have changes is .DelegationStartHeight
? I.e
.StakingOutputIdx
will always be the same.UnbondingOutput
will always be the same.DelegationStartHeight
can change from0
to some other value when providing proof of inclusion
So maybe lets be explicit here at compare only DelegationStartHeight
?
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.
sg will amend
This PR introduces an end-to-end test to validate that when both a staking transaction and an unbonding transaction are included in the same block, the delegation correctly transitions to the "UNBONDED" status.
This PR introduces an end-to-end test to validate that when both a staking transaction and an unbonding transaction are included in the same block, the delegation correctly transitions to the "UNBONDED" status.