Test status go 5925 #22011
Test status go 5925 #22011
Conversation
95% of end-end tests have passedFailed tests (2)Click to expandClass TestFallbackMultipleDevice:
Class TestWalletOneDevice:
Expected to fail tests (1)Click to expandClass TestCommunityMultipleDeviceMerged:
Passed tests (56)Click to expandClass TestActivityCenterContactRequestMultipleDevicePR:
Class TestFallbackMultipleDevice:
Class TestOneToOneChatMultipleSharedDevicesNewUi:
Class TestCommunityOneDeviceMerged:
Class TestOneToOneChatMultipleSharedDevicesNewUiTwo:
Class TestActivityMultipleDevicePRTwo:
Class TestGroupChatMultipleDeviceMergedNewUI:
Class TestCommunityMultipleDeviceMerged:
Class TestWalletMultipleDevice:
Class TestActivityMultipleDevicePR:
Class TestDeepLinksOneDevice:
Class TestWalletOneDevice:
Class TestCommunityMultipleDeviceMergedTwo:
|
|
@saledjenic thanks for the PR. Please take a look at the issues below. ISSUE 1 Incoming pending contact request appears from removed/blocked contacts after restoreSteps:
Actual result: incoming pending request from removed User B appears in activity center of User A. Status-debug-logs - 2025-02-03T152606.554.zip telegram-cloud-document-2-5262711513273098984.mp4 |
ISSUE 2 Blocking restored contact results in incoming pending contact request from this contactthis issue is most likely related to the above ISSUE 1 and probably has the same rootcause. Logging it separately just in case. Steps:
Actual result: incoming pending contact request from blocked User B appears for User A |
|
@pavloburykh it's better to continue discussing this with someone from the core team. They know better what they've implemented there, cause this is not about backing up/fetching the data only, but about the order of actions as well. What I've noticed in your video is that we don't use the old onboarding flow we had ~2+ years ago when we added the backup data feature, but instead, we let the users go straight to the app. That has its downsides. For example, I see a 3-word username instead of the display name, which tells me that the backed-up data was not fetched. Also, contact request messages are always around and nobody can guarantee that backed-up data are received before the message carrying the contact request. One more thing, you've backed up the data twice (it's a question if you've used a brand new Status profile or one you've already used before in which case more than 2 sets of backed-up messages are around, but I will assume that you tested it with a new Status profile and there are only 2 sets), so nobody can guarantee that the older one was not received first, then the request, then the latest data set or even not the latest set received at all. Did you use the same seed phrase for issue 2?
How did you verify this? And how did you know that the received list of contacts is from the last backup data set? Please read some concerns raised in this comment here status-im/status-go#6255 (review) Also, I said there that it's much better to say for activity notifications something like "Applied data are as they were on 11th of January 2025" and keep updating this instead "Profile details fetched successfully". Anyhow, before we had a longer fetching data stage while recovering the user from Waku and that was a more secure and better approach than what we do now. Before we were waiting for 30 seconds and in >90% the data should be received within that timeframe (if we rely on store nodes that work and they are synced (cause we keep those historical messages there)) for the rest of <10% cases we were waiting for 1.5 minutes more, after which we let the user in, but discarding all messages that may come later. That's a trade-off, but keeps the app consistent. Also, that flow should not be the first user's choice if there is another device set with the same seed phrase. Maybe I am wrong, but I somehow have a feeling that we've just changed the onboarding, to make it simple and short, without properly handling received messages after the user lands in the app. And that's the hardest part, not sure even if it's possible to sync all that properly at the later stage. Because there can be many data sets coming out of order and many action-related messages (like that one for contact request, added, blocked, removed) that come only once and being tried to apply for the state that is based on the lastly applied fetched data set which may not be the state when that message was initiated. That's a big problem. I understand that it's important to let the users land in the app as soon as possible, but that's nice if we're talking just about the wallet, our app is not just a wallet, it's a super app, with a lot of settings, chats, communities and so, so I am not sure that we should do that, but that's for another discussion. |
|
Hi @saledjenic, thank you for your comment. I am not sure I can deeply understand the problems you have raised here, so I agree that we need someone from mobile core team to help figuring out cc @ilmotta . Regarding your questions:
We have a separate issue for that #21827. 3 random-name is displayed until relogin. If there is a backed up display-name/default generated keys, it will be displayed after relogin.
yes, every time I have used brand new profile
The same to which seedphrase? As described in steps for ISSUE 2 the new user is created, backed up and then restored.
As you can see from the steps for ISSUE 2 there is only 1 backup set (at least 1 manual). I verified contact is restored by observing User B in contact list of User A.
As I have mentioned, my understanding of the issues raised by you is very limited. The described above looks weird for me, as I do not understand were those incoming contact request are coming from? If the contact request has been previously accepted (the status has changed) then why is it showing up again? Another weird thing in the context of ISSUE 1 is that User A receives incoming contact request even in case if User A initially was not the RECEIVER but the SENDER of the request to User B (which became his contact after accepting). Overall, maybe there is some sense in terms of technical implementation, but in terms of user experience it does not have any sense or logic. Regarding > so nobody can guarantee that the older one was not received first, then the request, then the latest data set or even not the latest set received at all why do we even receive any of the older sets of backed up data? shouldn't we receive the latest one available? |
Unfortunately no way to do that, cause you never know which one is the newest. We're operating in a decentralized environment and things are much harder than how they would be if there is a server containing all we need. Anyhow, I raised some questions in my comments, and I guess that should be discussed with the core team further and find the best (acceptable) solution, cause they know that code the best. |
|
Thanks @saledjenic. I am closing this mobile PR for now, as we probably will need another PR after mobile core will take a look. Let's for now continue and keep discussion in one place, for example in the initial issue. I have left the links to our discussion there. |
Created to test status-im/status-go#5925
Should fix #18096