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

Cleanup hash_ratchet_encrypted_messages periodically #5036

Closed
1 of 2 tasks
osmaczko opened this issue Apr 10, 2024 · 2 comments · Fixed by #5157
Closed
1 of 2 tasks

Cleanup hash_ratchet_encrypted_messages periodically #5036

osmaczko opened this issue Apr 10, 2024 · 2 comments · Fixed by #5157

Comments

@osmaczko
Copy link
Contributor

osmaczko commented Apr 10, 2024

Problem

The hash_ratchet_encrypted_messages table is utilized for storing messages that are unable to be decrypted. Currently, there is no mechanism in place for cleaning up this storage, particularly when the necessary encryption keys are not obtained. This lack of cleanup becomes problematic for clients who participate in communities but lack access to certain private channels, leading to uncontrolled and potentially infinite growth of the table. This growth adversely impacts performance, as the table is queried each time a hash ratchet is received, whether from store nodes or relays.

Screenshot from 2024-04-10 08-38-00

SELECT count(*) FROM hash_ratchet_encrypted_messages -> 653
SELECT timestamp FROM hash_ratchet_encrypted_messages ORDER BY timestamp ASC LIMIT 1 -> 1709136641 (Feb 28 2024)

Implementation

Clean up the hash_ratchet_encrypted_messages periodically. The condition would be: If a message remains unencrypted for 14 days, remove it.

Acceptance Criteria

  • remove unencrypted messages received more than 14 days ago from hash_ratchet_encrypted_messages

Notes

  • add index to hash_ratchet_encrypted_messages.key_id for immediate improvement

Future Steps

As a future improvement, we should not subscribe to chats (channels) we do not have permission for. This way, we would not be saving messages from private channels at all.

osmaczko added a commit that referenced this issue Apr 10, 2024
osmaczko added a commit that referenced this issue Apr 10, 2024
osmaczko added a commit that referenced this issue Apr 10, 2024
This time with proper migration timestamp.

part of: #5036
osmaczko added a commit that referenced this issue Apr 10, 2024
This time with proper migration timestamp.

part of: #5036
osmaczko added a commit that referenced this issue Apr 10, 2024
This time with proper migration timestamp.

part of: #5036
osmaczko added a commit that referenced this issue Apr 10, 2024
This time with proper migration timestamp.

part of: #5036
osmaczko added a commit that referenced this issue Apr 10, 2024
This time with proper migration timestamp.

part of: #5036
osmaczko added a commit that referenced this issue Apr 10, 2024
This time with proper migration timestamp.

part of: #5036
@jrainville jrainville modified the milestones: 2.28.0 Beta, 2.29.0 Beta Apr 10, 2024
@jrainville
Copy link
Member

As a future improvement, we should not subscribe to chats (channels) we do not have permission for. This way, we would not be saving messages from private channels at all.

@osmaczko have you opened an issue for this?

@osmaczko
Copy link
Contributor Author

As a future improvement, we should not subscribe to chats (channels) we do not have permission for. This way, we would not be saving messages from private channels at all.

@osmaczko have you opened an issue for this?

Not yet. Since we introduced indexing and have cleanup on the horizon, I am unsure if it's worth it. Many things can go wrong; there might be paths where subscription is skipped, and we'll end up with hard-to-investigate bugs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants