Some old messages are not removed from the device

[seifferth]

In the Settings for “Chats and Media”, below “Delete Old Messages”, I have set “Delete Messages from Device” to “After 5 weeks”. In general, this seems to work well. However, a very limited number of particularly old chats (the last five entries in my chat list) still contain messages. I just noticed this today and I was a little surprised, as I would have thought that these messages had already been deleted from my phone a long time ago.

Interestingly, these messages even predate the creation of my secret key. I also noticed that they are all “Group Messages” (specifically, non-encrypted emails with more than one recipient). I am not sure if the messages being group messages is somehow related to them not being deleted. In any case, you might want to make the deletion of old messages more robust. (Rather than removing them manually, I would rather wait for an update after which these messages are deleted. In cases where people do not notice that old messages are not deleted, such an update might even be critical.) Also, if there is some further information that I could provide – say, the result for a certain SQL query run against dc.db – I would be happy to do that as well.

Note: I had previously opened this issue as deltachat/deltachat-android#3904, where I was redirected here. I currently use Delta Chat for Android version 2.11.0.

[iequidoo]

select chat_id, timestamp, timestamp_rcvd from msgs where id in (<messageId list>) may help, messageId is displayed in the "Info" context menu

[seifferth]

`select chat_id, timestamp, timestamp_rcvd from msgs where id in (<messageId list>)` may help, messageId is displayed in the "Info" context menu

I cannot find `id` in the "Info" field. Only `rfc724_mid`. The result is as follows: ``` sqlite> select chat_id, timestamp, timestamp_rcvd from msgs ...> where rfc724_mid in ([...]); 329 1727195916 1756194309 326 1717666953 1756194195 327 1720277075 1756194195 325 1717647505 1756194195 328 1726632046 1756194195 328 1726632046 1756194195 328 1726632046 1756194195 ``` Does this listing help? If you have any further questions, just ask.

[iequidoo]

timestamp_rcvd is when a message was received and timestamp is when it was sent (not exactly, but roughly, timestamp_sent is the exact one). So it looks like the messages were delayed for more than a year. I have no idea how this could happen, Delta Chat renews timestamp_rcvd for webxdc messages when a new status update is received, but for "usual" messages we never change timestamp_rcvd. Anyway, it would be interesting to wait for 5 weeks (since 1756194195) and recheck if the messages are deleted, and if not, look at timestamp_rcvd again.

[seifferth]

Anyway, it would be interesting to wait for 5 weeks (since 1756194195) and recheck if the messages are deleted, [...]

The messages are gone now (at least from the UI; I didn't double-check the database yet). So that part seems to have worked properly.

`timestamp_rcvd` is when a message was received [...]

What exactly does "received" mean in this context. Is a message "received" when it is added to the database? Or is it "received" when the conversation is opened. All messages in question were sent to multiple recipients and appear as "groups". It is quite possible that I marked those messages as read using a different email client and that I then never opened these conversations in Delta Chat. At least until I noticed that the oldest "conversations" in my chat list were still showing message previews. Could this explain what happened?

[iequidoo]

Is a message "received" when it is added to the database?

Yes, almost, maybe with a gap of 1s because it's decrypted and processed before adding. I think that the reason may be not that the messages were delayed, but the clock is wrong on the sender side. Delta Chat limits the message "Date" to 1 minute in the future, but there's no limit in the past. Would be good if you can check when the messages were actually received by the server, e.g. look at their INTERNALDATE. Or if the sender can do the same.

[seifferth]

Yes, almost, maybe with a gap of 1s because it's decrypted and processed before adding. I think that the reason may be not that the messages were delayed, but the clock is wrong on the sender side.

I don't think so. Here's the relevant data for the first message: ``` sqlite> select chat_id, timestamp, timestamp_rcvd from msgs where [...] 325 1717647505 1756194195 ``` In human-readable form, these dates look like this: ``` $ date ***@***.*** -R # timestamp Thu, 06 Jun 2024 06:18:25 +0200 $ date ***@***.*** -R # timestamp_rcvd Tue, 26 Aug 2025 09:43:15 +0200 ``` The email itself has two different dates. The Date header says Thu, 6 Jun 2024 06:18:25 +0200 The sending email provider reports the same date: Thu, 06 Jun 2024 06:18:25 +0200 The receiving email provider indicates a 1 second delay in message delivery, as the various timestamps added on the receiving side are all: Thu, 6 Jun 2024 06:18:26 +0200 I am not entirely sure when the message was delivered to my phone, but I am pretty confident that this would have happened long before 'Tue, 26 Aug 2025 09:43:15 +0200', seeing that I use Delta Chat quite regularly. Could there be any other explanation?

[iequidoo]

Another possible explanation is that Delta Chat somehow missed these messages when they actually arrived, but then the folder was resynced (we resync a folder e.g. if its UIDVALIDITY changes) and Delta Chat found them. I think that only if you remember that you've seen these messages in Delta Chat a long ago, we can say that "Delete Messages from Device" doesn't work as expected, otherwise it may be another bug (may be even on the server side) and apparently it's not easy to debug because of the big time scale

[seifferth]

I think that only if you remember that you've seen these messages in Delta Chat a long ago, we can say that "Delete Messages from Device" doesn't work as expected, [...]

I believe I remember that I saw at least one of those messages in Delta Chat around the time it arrived. However, it is indeed a very long time scale, so I am anything but confident about this memory. I also believe to remember that I even removed the messages from the server before, or maybe around, the time of timestamp_rcvd. However, I do see that this issue is pretty hard to debug. So unless there is some other data I could provide to help figure out what happened, I guess we might conclude that while the delayed timestamps were surprising, the issue was not that bad in the end as the messages got deleted eventually.

[iequidoo]

I also believe to remember that I even removed the messages from the server before, or maybe around, the time of timestamp_rcvd.

So you removed the messages using some other client, but now they're on your server again? They're incoming messages, right (i.e. sent by your contacts)? Maybe they were re-sent? Delta Chat updates the "Date" header on resending, but maybe they're sent by another client?

[seifferth]

They're incoming messages, right (i.e. sent by your contacts)? Maybe they were re-sent?

Yes, they are incoming messages. I am pretty confident that they were not re-sent. The messages were not sent using Delta Chat.

> I also believe to remember that I even removed the messages from the server before, or maybe around, the time of timestamp_rcvd. So you removed the messages using some other client, but now they're on your server again?

I removed the messages using some other client. More specifically, I moved the files from a server-synchronized maildir into a non-synchronized (i.e. local-only) maildir and then invoked `mbsync --expunge-far` to remove those messages from the server. I do this occasionally. The messages did not reappear on the server, so I suppose that they must have been synchronized to my phone before I removed them from the server. Looking at my local maildir in more detail, it seems that I last performed this offlineing operation on 26 August 2025. Could it be that removing the message from the server caused timestamp_rcvd to be set?

[iequidoo]

Could it be that removing the message from the server caused timestamp_rcvd to be set?

There's no such a code in Core and it can't even know that you expunge the folder, so i think that smth went wrong and the messages were actually received on August 26. Maybe they were received before, then deleted by the "Delete Messages from Device" logic and then received again.

[r10s]

closing this issue as there is no way to reproduce, it is unclear if really smth went wrong on Delta Chat side or eg. some clocks were wrong, and the messages seems to be deleted finally.

closing during issue gardening time as there is no actionable item and for now, resources are spent better on other issues

if new insights come up, we can open a new, more focused and actionable issue

[seifferth]

Maybe they were received before, then deleted by the "Delete Messages from Device" logic and then received again.

I guess that would be a possibility. I.e. that the messages were originally deleted from the device and then somehow re-received in the process of removing all old messages from the server.

[...] it is unclear if really smth went wrong on Delta Chat side or eg. some clocks were wrong [...]

I checked the timestamps (see above) and this issue is definitely not about clocks being wrong. The best possible explanation is indeed that the messages were re-synced, yet I do not know why. I agree that "there is no actionable item" for now.