Broken contact request notification appears for contact request sender if contact request receiver starts sending messages before sender receives signal about contact request acception

[pavloburykh]

This is a very old issue. Haven't found it in repo so logging it now. In case you will find a duplicate feel free to close this one

Steps:

1. User A sends contact request to User B
2. Go offline by User A. (NOTE: we need to do this in order to easily generate the required condition. In real life it can happen due to network problems or issues on Waku side.
3. Accept contact request by User B.
4. Send a stack of messages in 1-1 chat by User B
5. Come back online by User A
6. Check activity center for notifications by User A when connection reestablished

Actual result: notification with broken contact request from User B appears in Activity center for User A. In fact it is not even contact request as User B has not sent any requests but accepted it from User B. What happens here is in case of delay of receiving by User A the signal about User B has accepted his CR, the messages sent by User B turn to appear as such broken contact requests notifications in activity center for User A (as User B is not a contact for User A yet despite he has already accepted request and is able to send messages). Such notification cannot be deleted as it is not responsive for swipes. It can be read only by using Mark all as read function.

User__B_cr_receiver.zip User_A_cr_sender.zip

https://github.com/user-attachments/assets/91a25413-165c-4ba0-9f7b-7663612524d0

Additional Information

• Status version: nightly
• Operating System: Android, iOS

[churik]

From discussion with @ilmotta It shouldn't be possible from the user perspective to do 4 step without acknowledgement from the receiver side.

That's something for both clients to look into.

[churik]

I don't think that it is feasible to finish investigation in 2.32, given the desired release cut date. Deferring the issue, please be free to move it back if you think there is a room for it @ilmotta

[ilmotta]

@pavloburykh what's your take from this comment https://github.com/status-im/status-mobile/issues/21438#issuecomment-2419422325 ?

[pavloburykh]

@pavloburykh what's your take from this comment #21438 (comment) ?

@ilmotta @churik from one point, solution proposed by Tetiana would fix current problem. From user perspective the solution is not ideal, as it would be confusing for me, as contact request receiver why I cannot send messages right after accepting incoming contact request. I believe input from design team would be helpful here as well. cc @xAlisher

[ilmotta]

@pavloburykh what's your take from this comment #21438 (comment) ?

@ilmotta @churik from one point, solution proposed by Tetiana would fix current problem. From user perspective the solution is not ideal, as it would be confusing for me, as contact request receiver why I cannot send messages right after accepting incoming contact request. I believe input from design team would be helpful here as well. cc @xAlisher

I see now what you mean @pavloburykh about the UX part. Most users would expect being able to immediately send messages after accepting a CR, as this is natural in centralized messengers where a central server is always online on behalf of users.

Thinking deeper now, I believe the best experience is if Alice and Bob can exchange messages without ever caring about each other's online state. Anything other than that and we might create a fragile solution because Alice and Bob can both be in highly intermittent connections. Sometimes the best is to solve for the worst case, which will cover all cases.

@jrainville what's your take on this problem? There's probably a way to simulate the case of this issue in a test in status-go and derive a more robust solution.