fix: expect single synthetic lock per native lock ID #5265
Conversation
| // DeleteAllSyntheticLocks iterates over given array of synthetic locks and deletes all individual synthetic locks. | ||
| func (k Keeper) DeleteAllSyntheticLocks(ctx sdk.Context, lock types.PeriodLock, synthLocks []types.SyntheticLock) error { | ||
| if len(synthLocks) == 0 { | ||
| return nil | ||
| } | ||
|
|
||
| for _, synthLock := range synthLocks { | ||
| err := k.DeleteSyntheticLockup(ctx, lock.ID, synthLock.SynthDenom) | ||
| if err != nil { | ||
| return err | ||
| } | ||
| } | ||
| return nil | ||
| } |
There was a problem hiding this comment.
No longer needed. We use DeleteSyntheticLockup directly now since we never expect multiple synthLocks anymore
czarcas7ic
changed the title
| // Error is returned if: | ||
| // - there are more than one synthetic lockup objects with the same underlying lock ID. | ||
| // - there is no synthetic lockup object with the given underlying lock ID. | ||
| func (k Keeper) GetSyntheticLockupByUnderlyingLockId(ctx sdk.Context, lockID uint64) (types.SyntheticLock, error) { | ||
| store := ctx.KVStore(k.storeKey) | ||
| iterator := sdk.KVStorePrefixIterator(store, combineKeys(types.KeyPrefixSyntheticLockup, sdk.Uint64ToBigEndian(lockID))) |
There was a problem hiding this comment.
If we are directly using key -value pair I think we should implement this without using iterators
There was a problem hiding this comment.
Removed iterator here e0ecfea
There was a problem hiding this comment.
After looking into this, I don't think we can do this without a large refactor / state migration. We are currently keying by lockID and synthDenom, which is why we need to use the iterator. We absolutely do not need the synthDenom in the key, but if we removed it, we would need to do a state migration of all currently existing state entires.
I am going to revert back to the iterator method, but will wait for an ack on this before merging @mattverse
x/lockup/client/cli/query.go
Outdated
| GetCmdSyntheticLockupsByLockupID(), | ||
| GetCmdSyntheticLockupByLockupID(), |
There was a problem hiding this comment.
Suggest avoiding breaking CLI and instead adding a new CLI
There was a problem hiding this comment.
Added back the old CLI cmd and added deprecated in the description 7bd3955
|
Merging since 2 ACKs and all feedback seems addressed |
* single synth lock per lock ID * add changelog entry * deprecate SyntheticLockupsByLockupID * small nits * add deprecated to underlying messages * remove iterator * add IsNil check * add back iterator * add back old CLI command
Closes: #5246
What is the purpose of the change
After doing some investigation, it turns out that we should never have multiple synthetic locks be assigned to a single lock ID. Despite this, some of the functions (such as
GetAllSyntheticLockupsByLockup) implied that this was possible by expecting an array of synthetic locks as the return value.After feeling confident that my understanding of synthetic locks to underlying locks was correct, I removed this from functions and tests to prevent others from being confused in the future (which also indirectly solves the issue I made for migration).
Testing and Verifying
Documentation and Release Note
Unreleasedsection ofCHANGELOG.md?Where is the change documented?
x/{module}/README.md)