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

Retention policy not working without any new activity #12093

Closed
qspweissen opened this issue Sep 18, 2018 · 8 comments
Closed

Retention policy not working without any new activity #12093

qspweissen opened this issue Sep 18, 2018 · 8 comments
Assignees

Comments

@qspweissen
Copy link

Description:

We are currently testing the retention policy and we have the behavior that channels, rooms and private messages are not deleted if there is no new message/activity. When someone writes a new message, messages older than one day were deleted after 30 minutes. But without a new message, we can see messages older than 1 day.

Settings:
2018-09-18 12_22_04-conti - quinscape chat
2018-09-18 12_22_08-conti - quinscape chat

Steps to reproduce:

  1. Write a message in a channels, rooms or direct messages
  2. Wait one day and do not write any new message
  3. After 1 day and 31 minutes you can see older messages
  4. If i write a new message and wait 30 minutes, older messages were deleted

Expected behavior:

I expect that alle messages will be deleteted after 1 day even if no new message was written

Actual behavior:

2018-09-18 12_20_33-conti - quinscape chat

Server Setup Information:

  • Version of Rocket.Chat Server: 0.69.1
  • Operating System: Debian 9
  • Deployment Method: Official Rocket.Chat docker deployment image
  • Number of Running Instances: 1
  • DB Replicaset Oplog:
  • NodeJS Version: 8.11.3
  • MongoDB Version: 3.2
@fcoppolani
Copy link

I can reproduce the same behaviour on 0.69.2 with 2 running instances

@localguru
Copy link
Contributor

+1 same here on 0.69.2

@vynmera
Copy link
Contributor

vynmera commented Sep 26, 2018

This behaviour is originally on purpose, as added by @ggazzo, and also discussed in #11725, as it adds a performance boost.

However, it's worth the effort to consider making this optional or removing this behavior altogether in favor of faster deletion.

I've been very busy lately, so I don't have much time to pick this up. But if I do have the time, I'll try to pick it up, together with some other related issues.

@ggazzo ggazzo added this to the 0.71.0 milestone Sep 27, 2018
@ggazzo ggazzo self-assigned this Sep 27, 2018
@hanynowsky
Copy link

hanynowsky commented Nov 23, 2018

Actually, for our case, we do not care for processing power. So the ideal is to add a boolean option that allows the user to select whether he/she wants to force pruning or keep the standard behavior:

  • Standard behavior = Do not trigger pruning unless channel has new activity
  • Forced behavior = Prune the channel despite whether there is activity or not.

As a workaround, we are using a crontabbed script that calls the API and posts a dummy message every 24 hours, on every single channel. Which is so ugly :(

Thanks for your reactiveness.

@ggazzo Please change the milestone to 0.72.0 as 0.71.0 is already packaged without the fix.

@theorenck theorenck modified the milestones: 0.71.0, Short-term Dec 12, 2018
@ggazzo ggazzo modified the milestones: Short-term, 0.73.0 Dec 12, 2018
@ggazzo
Copy link
Member

ggazzo commented Dec 12, 2018

sorry guys I was/am working with another issues, this week I will fix :)

@danielslyman
Copy link

+1

@theorenck theorenck removed this from the 0.73.0 milestone Mar 27, 2019
@mddvul22
Copy link

Any progress on this bug?

@ggazzo
Copy link
Member

ggazzo commented Oct 17, 2019

closed by #15252

@ggazzo ggazzo closed this as completed Oct 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants