-
Notifications
You must be signed in to change notification settings - Fork 53
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
bug: Waku Store returns duplicate messages #1502
Comments
I expect the setup above to use the in-memory db. As nwaku uses sqlite by default, I have changed the js-waku test harness to also use sqlite. This resulted in the same behaviour. commit that replaces the usage of in-memory db with sqlite: waku-org/js-waku@60b7912 nwaku logs: js-waku logs:
|
So, if I understood correctly, the scenario is as follows: Given a wakunode instance with "JSON-RPC API server", "Waku relay", "Waku store" and "Waku archive" capabilities enabled
When a js-waku client connects to this node's JSON-RPC API server
And using the relay JSON-RPC API publishes 20 messages (via "post_waku_v2_relay_v1_message")
Then the 20 messages should be relayed to the network (pub-sub topic)
And the 20 messages should be persisted in the node's Waku archive (in the DB)
And the 20 messages stored in the Waku archive should be retrievable via the Waku store query protocol. Is this correct? |
Based on the previous scenario, I did some tests:
|
Checking your logs I see something that looks suspicious:
I see that it performs 9 queries before receiving an empty cursor. If there are only 20 messages in the archive, the queries can't retrieve 44 items. I need to check the "query chain" criteria. |
Ok, the issue seems that is related to the "backwards" pagination. I managed to reproduce it with a backwards pagination query chain.
@fryorcraken @jm-clius I have one question:
|
In a scenario where the app is freshly loaded and hence does not have knowledge of any previous messages (can;t create a cursor), I'd expect backward pagination to be used to retrieve and display latest messages first. Most likely (and contrary to the test), the pagination would stop on a user/app defined criteria which would likely be based on the number of messages retrieved. Then moving forward, the app can store the oldest/earliest messages and do further queries based on user action/network state using a cursor. |
Confirmed fixed. Found new issue: #1514 |
Problem
js-waku interop test:
post_waku_v2_relay_v1_message
JSON RPC APIExpected: 20 messages are returned
Actual: 44 messages are returned
Impact
Seems to be a critical bug until investigation is cleared.
To reproduce
From a js-waku clone:
nwaku logs will be present in
./log
folderNote nwaku is executed with the following arguments:
and env var:
Screenshots/logs
nwaku logs:
nwaku_Waku_Store_Generator.log
js-waku logs:
Shows the dupe messages.
nwaku version/commit hash
v0.14.0
The text was updated successfully, but these errors were encountered: