-
Notifications
You must be signed in to change notification settings - Fork 13k
fix: removing files from e2ee rooms do not remove their messages #38379
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
base: develop
Are you sure you want to change the base?
Conversation
|
Looks like this PR is not ready to merge, because of the following issues:
Please fix the issues and try again If you have any trouble, please check the PR guidelines |
🦋 Changeset detectedLatest commit: 25b152c The changes in this PR will be included in the next version bump. This PR includes changesets to release 40 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughThis PR ensures removed attachments from encrypted messages are consistently represented and handled: adds a Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant UploadService
participant MessagesDB
participant Decryptor
Note over Client,MessagesDB: Removal flow for encrypted message with file
Client->>UploadService: Request remove message / file
activate UploadService
UploadService->>MessagesDB: Update message attachments -> `removed-file` (type, color, text, fileId?)
deactivate UploadService
Note over Client,Decryptor: Client receives updated message
Client->>Decryptor: Decrypt message content
activate Decryptor
Decryptor->>Decryptor: Detect `removed-file` attachments (isRemovedFileAttachment)
Decryptor->>Client: Return decrypted message with removed-file placeholders
deactivate Decryptor
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #38379 +/- ##
===========================================
+ Coverage 70.78% 70.85% +0.07%
===========================================
Files 3159 3160 +1
Lines 109401 109788 +387
Branches 19700 19709 +9
===========================================
+ Hits 77435 77786 +351
- Misses 29929 29975 +46
+ Partials 2037 2027 -10
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No issues found across 12 files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@apps/meteor/client/lib/e2ee/rocketchat.e2e.room.ts`:
- Around line 672-678: The second early-return check "if
(!deletedAttachments.length) { return message; }" is redundant because
"!deletedAttachments.length" is already part of the earlier compound condition;
remove the duplicate if-block and keep only the initial guard that checks
deletedAttachments, message.attachments, and content.attachments so the function
returns once when there are no deleted attachments or missing attachments (refer
to the variables deletedAttachments, message.attachments, and
content.attachments to locate the redundant check).
🧹 Nitpick comments (1)
apps/meteor/client/lib/e2ee/rocketchat.e2e.room.ts (1)
680-701: Consider using.find()instead of manual loop for cleaner code.The manual
for...ofloop can be simplified.♻️ Suggested refactor
message.attachments = message.attachments.map((att) => { if (!isFileAttachment(att)) { return att; } if (deletedAllAttachment) { return deletedAllAttachment; } const fileId = att.fileId || message.file?._id; if (!fileId) { return att; } - for (const removedAttachment of deletedAttachments) { - if (removedAttachment.fileId === fileId) { - return removedAttachment; - } - } - - return att; + return deletedAttachments.find((removed) => removed.fileId === fileId) ?? att; });
Proposed changes (including videos or screenshots)
On e2ee messages, the link between the message and the file is also being encrypted. This makes the server unable to delete files based on messages and also unable to delete messages based on files.
This PR changes the backend to save the metadata of the encrypted file on the message (just like it does for non-encrypted messages), so that any code that checks for links between files and messages can still find it.
It also changes the message to keep a list of files that have been deleted on the server so that the client may ignore any references to those files on decrypted data.
The only thing being saved to the message is related to the encrypted version of the file, so attributes like name, format and size will not reflect the real file - as the server doesn't have any info about it.
Issue(s)
CORE-1776
Steps to test or reproduce
Further comments
Summary by CodeRabbit
Bug Fixes
Improvements
✏️ Tip: You can customize this high-level summary in your review settings.