Problem: strange failure in sim test with sdk 0.46

[yihuang]

After upgrade to sdk 0.46, it's strange that this commit is necessary for the sim test to pass. Maybe there's some deeper issue in the SDK sim test itself.

[adu-crypto]

If we reset this commit(git reset --hard HEAD~1), and print some debugging information:

Simulating... block 22/50, operation 0/357. random unbonding entry index: 1
staking cancel bond amount: 2663067285, balance: 5485945019
index 0 entry: balance: "2397748260"
completion_time: "2103-10-03T03:17:50Z"
creation_height: 4
initial_balance: "2397748260"

index 1 entry: balance: "5485945019"
completion_time: "2103-10-03T03:17:50Z"
creation_height: 4
initial_balance: "5485945019"

actual unboding entry index: 0
skaing actual cancel amount: 2663067285, actual balance: 2397748260

we can find that we have tow unBondingDelegationEntries with the same CreationHeight.
By comparing the index and the balance, we find that the intended unBondingDelegationEntry is no matched with the actual unBondingDelegationEntry that was executed by the staking msgServer.

[adu-crypto]

Referring to the sdk v0.46 code , we find how msgServer.CancelUnbondingDelegation find the matched unBondingDelegationEntry based on CreationHeight :

for i, entry := range ubd.Entries {
		if entry.CreationHeight == msg.CreationHeight {
			unbondEntry = entry
			unbondEntryIndex = int64(i)
			break
		}
	}

[adu-crypto]

definitely, this logic is not accurate and could match with unintended unBondingDelegationEntry if we have two entries with the same CreationHeight.
Besides, it is legal to have two entries with the same CreationHeight but different balance according to the staking module specifications.

[tomtau]

open an issue on SDK?

[adu-crypto]

open an issue on SDK?

sure

[yihuang]

fixed in sdk.