-
Notifications
You must be signed in to change notification settings - Fork 62
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: inconsistent / missing messages in status.prod fleet #1400
Comments
|
The current version deployed in We recommend upgrading to the latest release version, |
Status mobile issue: status-im/status-mobile#14390 |
I draw some conclusions over the weekend; this is the update:
|
From PR #1406:
At this moment, we are working towards providing a developer preview version (a build from the |
While analyzing some of the queries observed in the Kibana logs, I noticed one thing:
The kibana record link. This query logged here corresponds to the following query parameters: contentFilters:
- contentTopic: "/waku/1/0xd6861a81/rfc26"
pubsubTopic: "/waku/2/default-waku/proto"
pagingInfo:
pageSize: 500 # <- This is unnecessarily high, nwaku caps this to 100
cursor:
pubsubTopic: "/waku/2/default-waku/proto"
senderTime: 1666380751000000000 # 2022-10-21 19:32:31
receiverTime: 1666380751000000000 # 2022-10-21 19:32:31
digest: "0x6e88e64433b169865ba45faafe77ee464b9a9e0a0acd144778af69980e11f6cc"
direction: "FORWARD"
startTime: 1668767108000000000 # 2022-11-18 10:25:08
endTime: 1668767638000000000 # 2022-11-18 10:33:58 Even though this may not explain the inconsistencies in the query results, there are a couple of things that should be investigated:
@richard-ramos @cammellos Can you check where those queries for 500 messages are coming from? Where is that cursor coming from? Is it necessary to request 500 messages in one query? Do all those messages fit the Desktop/Mobile/Web app screen? |
The issue was located in the Nwaku SQLite bindings wrapper. See #1415 for more information. Closing the issue since the tests performed confirmed that the problem was fixed. |
Issue fixed from nwaku's perspective. Tested for consistency and performance at high query rates. Assigning to Client Team to verify:
Feel free to close when confirmed. |
@cammellos @richard-ramos afaik this issue has been addressed and tested? Can we close? |
Issue addressed and tested 🚀 |
I created the following project to help debug this scenario: https://github.com/richard-ramos/test-waku-query
/waku/2/default-waku/proto
/waku/1/0xd6861a81/rfc26
1668613188
, // Convert it to nano1668696055
, // Convert to nanoand got these results:
What the script does is send the same query 3 times to each node of
status.prod
fleet and if a cursor is returned, iterate over it. I find it interesting that the results are not consistent. (for each attempt, i expect the results to be the same for the same node for the same time period in the past).Another attempt at running the same query:
The results are not deterministic at all for the same time period
Changing the query to retrieve 10 messages per page, returns interesting results as well: (these results are on a single node)
Here, the same request sent twice, and different responses are received. Notice the cursor is empty in one of these responses, also, the number of messages returned is different
The text was updated successfully, but these errors were encountered: