Skip to content
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

feat: improve quote event loading [SQSERVICES-1834] #14632

Merged
merged 10 commits into from
Feb 16, 2023

Conversation

tlebon
Copy link
Contributor

@tlebon tlebon commented Feb 6, 2023

BugSQSERVICES-1834 "You cannot see this message." in reply to own message


PR Submission Checklist for internal contributors

  • The PR Title

    • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
    • contains a reference JIRA issue number like SQPIT-764
    • answers the question: If merged, this PR will: ... ³
  • The PR Description

    • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

What's new in this PR?

Issues

Tries a different approach to solve the 'message not found' bug in #14630. That solution caused some unexpected side effects.

Causes (Optional)

As loadEvent is more generic than expected, it is causing some issues in various locations.

Solutions

The solution to this is to create other methods to be consumed in specific locations.

@codecov
Copy link

codecov bot commented Feb 8, 2023

Codecov Report

Merging #14632 (b41c83a) into dev (5a87c27) will increase coverage by 0.16%.
The diff coverage is 30.43%.

@@            Coverage Diff             @@
##              dev   #14632      +/-   ##
==========================================
+ Coverage   42.60%   42.76%   +0.16%     
==========================================
  Files         615      618       +3     
  Lines       21041    21132      +91     
  Branches     4806     4839      +33     
==========================================
+ Hits         8965     9038      +73     
+ Misses      10960    10959       -1     
- Partials     1116     1135      +19     

@tlebon tlebon changed the title runfix: revert message not found reversion feat: improve quote event loading Feb 9, 2023
@tlebon tlebon changed the title feat: improve quote event loading feat: improve quote event loading [SQSERVICES-1834] Feb 9, 2023
Comment on lines 978 to 979
return this.messages().find(messageEntity => (messageEntity as ContentMessage)?.replacing_message_id === messageId);
}
Copy link
Contributor

@przemvs przemvs Feb 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe use isContentMessage instead of as ? 🤔

Copy link
Contributor

@przemvs przemvs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code LGTM, 1 comment ;)

@@ -78,7 +78,7 @@ export const MessageWrapper: React.FC<MessageParams & {hasMarker: boolean; isMes
isMsgElementsFocusable,
}) => {
const findMessage = (conversation: Conversation, messageId: string) => {
return messageRepository.getMessageInConversationById(conversation, messageId, true, true);
return messageRepository.getMessageInConversationByReplacementId(conversation, messageId);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Humm I think we also need to get the message by regular ID at this point. The replacing_id should only be a fallback in case we don't find the message by ID

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think the naming is confusing you here but it does indeed to either/or, not only replacingId

* @returns Resolves with the message
*/
async getMessageInConversationById(
async getMessageInConversationById(conversation: Conversation, messageId: string): Promise<StoredContentMessage> {
const messageEntity = conversation.getMessage(messageId);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the default value of this method is not to look up the local state. This might be a regression here (since now it always lookup to local state)

Copy link
Contributor Author

@tlebon tlebon Feb 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the default value is false and this is negated. so the default case is always to look up.

@@ -1197,7 +1218,7 @@ export class MessageRepository {
);
}

if (ensureUser && message.from && !message.user().id) {
if (message.from && !message.user().id) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's extract this logic to a different method and have a single responsibility for the getMessageInConversationByReplacementId.
This way the consumer can do:

const event = getMessageInConverstation(..) || getMessageInConversationByReplacementId()
const event = loadUsers(event);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i did something but i think based on your comment you would like something different

}

const records = (await this.storageService.getAll(StorageSchemata.OBJECT_STORE.EVENTS)) as EventRecord[];
return records
.filter(record => record.id === eventId && record.conversation === conversationId)
.filter(record => record.conversation === conversationId && record.data?.replacing_message_id === eventId)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's only lookup by replacing id at this point. The consumer is responsible for falling back to something else if it's not found

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the other function on L140, we are also checking by conversation && then id. (This was also the previous implementation) Should we change that as well or leave both the same?

I assume there was some logic to checking both, although the chances of an overlap here seem relatively astronomical to me. Still sort of unclear when this section of the function would be called anyway.

Copy link
Contributor

@atomrc atomrc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there are some parts that might have introduced behavior changes.

Copy link
Contributor

@atomrc atomrc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems solid 😎

@tlebon tlebon merged commit 2ac4ebd into dev Feb 16, 2023
@tlebon tlebon deleted the fix/revert-message-not-found branch February 16, 2023 13:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants