-
Notifications
You must be signed in to change notification settings - Fork 1k
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
V3: Storage is no longer emptied properly. #2970
Comments
It may be that the code is biased towards the days but I can not remember off the top of my head. Have you tried connecting to the database to see how many raw tables you have? FWIW Postal was not intended to store your messages long term, you should be doing that in whatever application you are using to create the emails and then you could also listen to webhooks and store the information for as long as you need. |
It used to work just fine. It would (at least I understood that) delete all the messages older than, and then continue until it would meet the storage limit. This seems to no longer be the case:
I've been doing my best to reduce the amount of storage time, since we've had issues with it being slow in the UI. But it's really useful to have a good backlog since users sometimes won't report that they're not receiving emails for several months. Regardless, the storage cap feature is not working any more. |
With nearly 200 days of raw messages, none of the settings seem to be working for you. Version 3 changed the cron to use scheduled tasks instead, I think there should be a |
Looks fine to me:
|
@willpower232 could you share how can we manually delete old emails like the task is doing? We are running out of space until a new release. |
You should be able to safely remove the |
I'm also having the same problem. From my logs running "postal logs worker | grep ProcessMessageRetentionScheduledTask, I get the following: worker_1 | 2024-05-27 03:00:28 +0000 INFO running task component=worker thread=tasks task=ProcessMessageRetentionScheduledTask This looks like the task is completed within a second. I couldn't find any logged errors associated with this task. |
I’m having the same issue. |
Describe the bug
Storage is no longer emptied properly.
See the screenshot. The limit is set to 15.5GB of storage and the server is currently using 18.8GB. I don't know if it's an issue with reporting or if there's an issue emptying the storage.
To Reproduce
Expected behaviour
Just like in V2 I expected the storage to be emptied nightly.
Environment details
The text was updated successfully, but these errors were encountered: