runfix: creation message not visible after accepting a connection #15987
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Problem
This PR #15935 fixed an issue with sending a connection from one device when the other is online, but it also introduced new issue: Every time after connection event was received (with any status) we were mapping a connection to a conversation what appeared to happen to frequently.
When accepting a connection request, we're mapping a connection to a conversation, right after that we're displaying this conversation, see: https://github.com/wireapp/wire-webapp/blob/runfix/connection-accept-empty-conversation/src/script/components/ConnectRequests/ConnectionRequests.tsx#L93.
The problem is that
.acceptConnectionRequest
triggers connection mapping logic (via amplify), and before conversation is created and saved in a local state, we call.getOrCreate1to1Conversation
again, creating a new conversation entity. Member message was loaded to the conversation entity that was not opened in the end, causing an empty conversation to be visible.Solution
The solution is to simply reduce the cases when connection is being mapped to a conversation. We map a connection only when connection request is sent (to maintain the fix for a bug described above), or was previously sent and now is accepted (old behaviour).
Screenshots/Screencast (for UI changes)
Checklist