Skip to content
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.

Sign up for GitHub

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

Jump to bottom

fix IterateInitTimeoutTimestamp #549

Merged
merged 3 commits into from
Dec 6, 2022
Merged

fix IterateInitTimeoutTimestamp #549

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
592d76b
fix IterateInitTimeoutTimestamp
MSalopek Dec 2, 2022
287450e
update comment
MSalopek Dec 6, 2022
f7cd3c3
apply suggested comment
MSalopek Dec 6, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions x/ccv/provider/keeper/keeper.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -785,6 +785,7 @@ func (k Keeper) DeleteInitTimeoutTimestamp(ctx sdk.Context, chainID string) {
}

// IterateInitTimeoutTimestamp iterates through the init timeout timestamps in the store
// store is iterated in alphabetical ascending order not in the order of insertion
mpoke marked this conversation as resolved.
Show resolved Hide resolved
func (k Keeper) IterateInitTimeoutTimestamp(ctx sdk.Context, cb func(chainID string, ts uint64) (stop bool)) {
store := ctx.KVStore(k.storeKey)
iterator := sdk.KVStorePrefixIterator(store, []byte{types.InitTimeoutTimestampBytePrefix})
Expand Down
14 changes: 8 additions & 6 deletions x/ccv/provider/keeper/keeper_test.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -305,9 +305,10 @@ func TestInitTimeoutTimestamp(t *testing.T) {
chainID string
expected uint64
}{
{expected: 5, chainID: "chain"},
{expected: 10, chainID: "chain1"},
{expected: 12, chainID: "chain2"},
// ordered alphabetically - descending
{expected: 5, chainID: "z-chain"},
{expected: 12, chainID: "b-chain"},
{expected: 10, chainID: "a-chain"},
}

_, found := providerKeeper.GetInitTimeoutTimestamp(ctx, tc[0].chainID)
Expand All @@ -317,14 +318,15 @@ func TestInitTimeoutTimestamp(t *testing.T) {
providerKeeper.SetInitTimeoutTimestamp(ctx, tc[1].chainID, tc[1].expected)
providerKeeper.SetInitTimeoutTimestamp(ctx, tc[2].chainID, tc[2].expected)

i := 0
i := 2
// store is iterated in alphabetical ascending order
// not in the order of insertion
providerKeeper.IterateInitTimeoutTimestamp(ctx, func(chainID string, ts uint64) (stop bool) {
require.Equal(t, chainID, tc[i].chainID)
require.Equal(t, ts, tc[i].expected)
i++
i--
return false // do not stop the iteration
})
require.Equal(t, len(tc), i)

for _, tc := range tc {
ts, found := providerKeeper.GetInitTimeoutTimestamp(ctx, tc.chainID)
Expand Down
6 changes: 2 additions & 4 deletions x/ccv/provider/keeper/relay.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -332,11 +332,9 @@ func (k Keeper) EndBlockCCR(ctx sdk.Context) {
if currentTimeUint64 > ts {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @MSalopek- can you add a comment on IterateInitTimeoutTimestamp (in different file), making it clear that it is not in order?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you also open an issue on the repo (put it in the v1.1 milestone) to make IterateInitTimeoutTimestamp go in order? That would be a little better because it would avoid uneccesary iteration.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can do: #561. Can't tag it as 1.1 though, maybe I'm missing some access rights?

Are we expecting loads of chains to be removed due to timeouts? If we're iterating 5-20 items this does not seem worthwhile.

// initTimeout expired
chainIdsToRemove = append(chainIdsToRemove, chainID)
// continue to iterate through all timed out consumers
return false
}
// break iteration since the timeout timestamps are in order
return true
// continue to iterate through all timed out consumers
return false
})
// remove consumers that timed out
for _, chainID := range chainIdsToRemove {
Expand Down