Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

storage_key_iter does return invalid second keys for StorageDoubleMap #11416

Open
2 tasks done
sea212 opened this issue May 15, 2022 · 3 comments
Open
2 tasks done

storage_key_iter does return invalid second keys for StorageDoubleMap #11416

sea212 opened this issue May 15, 2022 · 3 comments
Labels
J2-unconfirmed Issue might be valid, but it’s not yet known.

Comments

@sea212
Copy link
Contributor

sea212 commented May 15, 2022

Is there an existing issue?

  • I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

  • This is not a support question.

Description of bug

When using storage_key_iter on a StorageDoubleMap with a ReversibleStorageHasher other than Identity, the second keys that are returned contain wrong values.

I am not quite sure if storage_key_iter was ever designed to be used with StorageDoubleMaps. In that case, a note in the documentation is crucial, otherwise devs might mess up their storage by assuming that it will work.

Steps to reproduce

I created a repository that contains a rust crate with a minimal example and three tests that can be used as a reference.

  1. Create StorageDoubleMap using Blake2_128Concat or Twox64Concat hasher. The key types should be i32, the value should be u32
  2. Insert an example value in the storage, like: (-12, -34) = 56
  3. Use storage_key_iter to iterate over the keys and values. The second key in the retrieved value should not match the second key in the inserted value.
@bkchr
Copy link
Member

bkchr commented May 16, 2022

I checked this and the code is actually working, but storage_key_iter is only for storage maps and not double maps.

For a double map you actually need to do something like this:

let key_material = something;
let mut key_one_and_rest = K1Hasher::reverse(&key_material);
let k1 = K1::decode(&mut key_one_and_rest)?;
let key_two_material = K2Hasher::reverse(&key_one_and_rest);
let key_two = K2::decode(&mut &key_two_material[..])?'

But you can not control the key decoding from the function you are calling. I propose that you switch to generate_storage_alias! or to the new storage_alias (when it is merged). Then you don't need to use storage_key_iter.

@sea212
Copy link
Contributor Author

sea212 commented May 17, 2022

@bkchr Thanks for the clarification and for providing an alternative approach. I suggest to document that storage_key_iter should only be used for StorageMap (I can create the PR if desired).

@bkchr
Copy link
Member

bkchr commented May 17, 2022

Yeah a pr would be nice @sea212 :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
J2-unconfirmed Issue might be valid, but it’s not yet known.
Projects
None yet
Development

No branches or pull requests

2 participants