chore: allow to call store api endpoints without a storenode (#1575)

[Ivansete-status]

Chore

#1575

Comment

Separated change to always enable the store-rpc handler even though the 'storenode' param is not passed.

Additional info for new members

The storenode param is described ain:

nwaku/apps/wakunode2/config.nim

Line 212 in 0627b4f

storenode* {.

[jm-clius]

Yeah, makes sense to me!

[jm-clius]

Btw, if you use keywords such as "closes #1575" in your description, it will automatically close the related issue when this PR gets merged.

[LNSD]

Separated change to always enable the store-rpc handler even though the 'storenode' param is not passed.

These changes, to work, require the WakuNode to mount the WakuStoreClient without passing the --storenode configuration flag. Otherwise, IIRC, the Waku Store JSON-RPC API will return a 500, internal error: "waku store client not mounted".

And another question: How would the Waku Store JSON-RPC behave if no nodes support the waku store protocol in the peer manager?

In my opinion, the two things above should be addressed before merging these changes.

[LNSD]

Please, check my comment 🙂

[Ivansete-status]

Thanks for your comments @LNSD. I will tackle them straight away.

And another question: How would the Waku Store JSON-RPC behave if no nodes support the waku store protocol in the peer manager?

In this case it should return a 500, internal error: "No peer store nodes found" (or sth like that) because the client doesn't have means to provide the peer store address in JSON-RPC.. therefore, 500 should be returned.

[alrevuelta]

thanks for the pr! same concerns as @LNSD

• not sure it will work without mounting the waku store client. once fixed mind including couple of commands (wakunode --flags...) and a curl command to test that it works? we could even add a unit test for this.
• specify the error to be returned in case there are no peers supporting the store protocol. In this case selectPeer will return a none() and the request wont be completed.

[Ivansete-status]

In case of missing a peer-store-node, when calling get_waku_v2_store_v1_messages from the client side, this raises an exception (because it is raised here)

I added a test that validates this behavior.

How to test this manually

1. Start a solitaire node

   ./build/wakunode2 --log-level="DEBUG"
   

2. Send 'get_waku_v2_store_v1_messages':

   curl -d '{"jsonrpc":"2.0","id":"id","method":"get_waku_v2_store_v1_messages"}' --header "Content-Type: application/json" http://localhost:8545
   

   The curl command will show:

   {"jsonrpc":"2.0","id":"id","error":{"code":-32000,"message":"get_waku_v2_store_v1_messages raised an exception","data":"no suitable remote store peers"}}
   

[LNSD]

LGTM ✅

[LNSD]

LGTM ✅

[alrevuelta]

lgtm! thanks!

a clarification on this to ensure we are aligned.

In case of missing a peer-store-node, when calling get_waku_v2_store_v1_messages from the client side, this raises an exception (because it is raised here)

Would like to ellaborate on what In case of missing a peer-store-node means. A node has the following ways of having a peer-store-node:

• Configured via cli flag, which sets it as the preferred one (calls addServicePeer under the hood)
• Discovered and identified (either because we connect to it or it connected to us). This means that any node supporting the store protocol, can be a potential store node for us if no prefered one was configured.

I just confirmed this is the case with your fix, so no action required :)

./build/wakunode2 --rpc-admin=true --dns-discovery=true --dns-discovery-url=enrtree://AOGECG2SPND25EEFMAJ5WF3KSGJNSGV356DSTL2YVLLZWIV6SAYBM@prod.nodes.status.im --discv5-discovery=true

Now get_waku_v2_store_v1_messages works without provoding a store node. What happens under the hood is that an identified node supporting store is selected for the query.

curl -d '{"jsonrpc":"2.0","id":"id","method":"get_waku_v2_store_v1_messages"}' --header "Content-Type: application/json" http://localhost:8545