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.

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

state_getKeys wrongly returns an empty list #174

Closed
josepot opened this issue Feb 13, 2023 · 4 comments · Fixed by #178
Closed

state_getKeys wrongly returns an empty list #174

josepot opened this issue Feb 13, 2023 · 4 comments · Fixed by #178

Comments

@josepot
Copy link
Contributor

josepot commented Feb 13, 2023

I've created this sandbox on stackblitz to reproduce and isolate the issue.

In short, the issue is that smoldot -while connected to the polkadot network- returns an empty list of keys as a response to the following RPC request (which, in this example, asks for the keys of the staking.validators storage entry):

{
  "id":1,
  "jsonrpc":"2.0",
  "method":"state_getKeys",
  "params":["0x5f3e4907f716ac89b6347d15ececedca88dcde934c658227ee1dfafcd6e16903"]
}

while the exact same RPC request against wss://apps-rpc.polkadot.io/ returns a very long list of keys.

@rossbulat
Copy link

rossbulat commented Feb 13, 2023

Great, I experienced the same issue in the staking dashboard when fetching nominationPools.bondedPools, nominationPools.poolMembers entries also with Polkadot JS API.

@tomaka
Copy link
Contributor

tomaka commented Feb 13, 2023

Received proofs: logs.txt

@tomaka tomaka mentioned this issue Feb 13, 2023
@tomaka
Copy link
Contributor

tomaka commented Feb 13, 2023

I just wanted to point out that state_getKeys takes a long time to execute, and that's normal. The fix is paritytech/substrate#10623, but it's taking ages to land.

After paritytech/substrate#10623, #177 will improve the execution time further.

@josepot
Copy link
Contributor Author

josepot commented Feb 13, 2023

I just wanted to point out that state_getKeys takes a long time to execute, and that's normal. The fix is paritytech/substrate#10623, but it's taking ages to land.

After paritytech/substrate#10623, #177 will improve the execution time further.

Thanks for looking into this @tomaka and also for sharing all this context. Much appreciated!

I always assumed that it would take a rather long time for a light-client to resolve a state_getKeys request. That makes sense, ofc. However, what's currently happening is that smoldot resolves the request with an empty list.

So, are you saying that it's not possible for smoldot to resolve the state_getKeys requests (at all) until paritytech/substrate#10623 is solved? Or that it's possible to solve this issue before at the expense of having to wait for a very long time to get the response?

EDIT:

Apologies! I just noticed #178 Thanks @tomaka !

tomaka added a commit that referenced this issue Feb 13, 2023
* Add a regression test

* Fix the bug, I think

* CHANGELOG

* Tweak comment

* Update test proofs

* Add the expected values

* CHANGELOG PR number

* Tweak CHANGELOG a bit
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants