starred/cypht

Fork 0

mirror of https://github.com/cypht-org/cypht.git synced 2026-04-26 05:26:00 +03:00

[GH-ISSUE #190] Deleting messages sometimes does not delete them #156

New issue

Closed

opened 2026-02-25 21:34:18 +03:00 by kerem · 11 comments

kerem commented

2026-02-25 21:34:18 +03:00

Owner

Originally created by @jasonmunro on GitHub (Apr 21, 2017).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/190

Originally assigned to: @jasonmunro on GitHub.

I periodically run into this, usually on the mobile UI (though I don't know if that is related), but sometimes deleting messages from a message list simply does not delete them. The UI removes them, but when that IMAP source is updated, the messages are still there.

I have not figured out the right conditions to repeat this. My original thought was this was over aggressive caching, but it still seems to happen even with the IMAP cache disabled. I received another report of this behavior so I figured I better get an issue going to see if I can figure out what is going on.

Originally created by @jasonmunro on GitHub (Apr 21, 2017). Original GitHub issue: https://github.com/cypht-org/cypht/issues/190 Originally assigned to: @jasonmunro on GitHub. I periodically run into this, usually on the mobile UI (though I don't know if that is related), but sometimes deleting messages from a message list simply does not delete them. The UI removes them, but when that IMAP source is updated, the messages are still there. I have not figured out the right conditions to repeat this. My original thought was this was over aggressive caching, but it still seems to happen even with the IMAP cache disabled. I received another report of this behavior so I figured I better get an issue going to see if I can figure out what is going on.

kerem

2026-02-25 21:34:18 +03:00

closed this issue
added the
bug

imap
labels

kerem commented

2026-02-25 21:34:19 +03:00

Author

Owner

@jasonmunro commented on GitHub (Aug 10, 2017):

I have only seen this once since creating this issue, on mobile.

@jasonmunro commented on GitHub (Aug 10, 2017): I have only seen this once since creating this issue, on mobile.

kerem commented

2026-02-25 21:34:19 +03:00

Author

Owner

@ulfgebhardt commented on GitHub (Jan 2, 2018):

I never had this Issue on a stable Internet Connection - i think this can be closed unless you want to build in some Client-Side Message queue which makes sure the command is porperly recieved by the Server.

@ulfgebhardt commented on GitHub (Jan 2, 2018): I never had this Issue on a stable Internet Connection - i think this can be closed unless you want to build in some Client-Side Message queue which makes sure the command is porperly recieved by the Server.

kerem commented

2026-02-25 21:34:19 +03:00

Author

Owner

@dumblob commented on GitHub (Jan 2, 2018):

Well, this depends on the user-friendliness we'll end up with in the end. If I click delete and everything seems like it got deleted, but after a restart/refresh it shows up again, then it's a very poor user experience and shall be definitely improved. But if it shows a warning, that the message could not be deleted, then it's fine.

@dumblob commented on GitHub (Jan 2, 2018): Well, this depends on the user-friendliness we'll end up with in the end. If I click delete and everything seems like it got deleted, but after a restart/refresh it shows up again, then it's a very poor user experience and shall be definitely improved. But if it shows a warning, that the message could not be deleted, then it's fine.

kerem commented

2026-02-25 21:34:19 +03:00

Author

Owner

@jasonmunro commented on GitHub (Jan 2, 2018):

@ulfgebhardt I'm about 99.9% sure this is a connection issue. The UI immediately removes deleted messages from a list when you hit delete, meanwhile we send a request to the server to do the real work. If that request does not complete, the next time the UI updates the messages come back.

I really don't want to build a client side message queue. Like really really don't want to :) What should happen at the very least is a notice that the request to delete the messages failed. Why this is not happening I cannot yet explain.

@jasonmunro commented on GitHub (Jan 2, 2018): @ulfgebhardt I'm about 99.9% sure this is a connection issue. The UI immediately removes deleted messages from a list when you hit delete, meanwhile we send a request to the server to do the real work. If that request does not complete, the next time the UI updates the messages come back. I really don't want to build a client side message queue. Like really really don't want to :) What should happen at the very least is a notice that the request to delete the messages failed. Why this is not happening I cannot yet explain.

kerem commented

2026-02-25 21:34:19 +03:00

Author

Owner

@ulfgebhardt commented on GitHub (Jan 3, 2018):

How about a Warning in the Top-Dropdown-Popup, that there was a Problem performing the Delete-Request?

The ajax should fail with an Errorcode on an interrupted Connection.

To test you can Pull the Networkcable before pressing delete.

@ulfgebhardt commented on GitHub (Jan 3, 2018): How about a Warning in the Top-Dropdown-Popup, that there was a Problem performing the Delete-Request? The ajax should fail with an Errorcode on an interrupted Connection. To test you can Pull the Networkcable before pressing delete.

kerem commented

2026-02-25 21:34:19 +03:00

Author

Owner

@jasonmunro commented on GitHub (Jan 3, 2018):

That should be happening now, something like "An error occurred communicating with the server". I just tested this (desktop) and it correctly displayed the error (I used chromium and put it temporarily offline with the dev tools), however the "deleted" messages are still hidden from the list until the next update.

One thing I recall about mobile is that it's possible for the error to only be visible from the menu list because of some CSS issues, so maybe it's actually firing the notice, but it's not visible unless you open the menu. I will do some testing to confirm if that is the case.

@jasonmunro commented on GitHub (Jan 3, 2018): That should be happening now, something like "An error occurred communicating with the server". I just tested this (desktop) and it correctly displayed the error (I used chromium and put it temporarily offline with the dev tools), however the "deleted" messages are still hidden from the list until the next update. One thing I recall about mobile is that it's possible for the error to only be visible from the menu list because of some CSS issues, so maybe it's actually firing the notice, but it's not visible unless you open the menu. I will do some testing to confirm if that is the case.

kerem commented

2026-02-25 21:34:19 +03:00

Author

Owner

@dumblob commented on GitHub (Jan 4, 2018):

however the "deleted" messages are still hidden from the list until the next update.

This is one thing, but the other is, whether the list entry of the message, which shall have been deleted, but wasn't due to a communication error with the server, is immediately displayed again after it becomes known, that an error occurred communicating with the server or whether one needs to wait for the next update or even do the update manually to get the list entry shown again.

@dumblob commented on GitHub (Jan 4, 2018): >however the "deleted" messages are still hidden from the list until the next update. This is one thing, but the other is, whether the list entry of the message, which shall have been deleted, but wasn't due to a communication error with the server, is immediately displayed again after it becomes known, that an error occurred communicating with the server or whether one needs to wait for the next update or even do the update manually to get the list entry shown again.

kerem commented

2026-02-25 21:34:19 +03:00

Author

Owner

@jasonmunro commented on GitHub (Jan 4, 2018):

Yep. The simplest but least efficient way to deal with this is to queue up a refresh automatically if the delete operation fails. A slightly more complicated method would be to capture the removed row, pass it to the callback, and re-insert it into the list on failure.

@jasonmunro commented on GitHub (Jan 4, 2018): Yep. The simplest but least efficient way to deal with this is to queue up a refresh automatically if the delete operation fails. A slightly more complicated method would be to capture the removed row, pass it to the callback, and re-insert it into the list on failure.

kerem commented

2026-02-25 21:34:19 +03:00

Author

Owner

@dumblob commented on GitHub (Jan 5, 2018):

The simplest but least efficient way to deal with this is to queue up a refresh automatically if the delete operation fails.

Correct. But I have to admit that my experience with such full refreshes was always painful. If anything, then rather the "callback" method.

@dumblob commented on GitHub (Jan 5, 2018): >The simplest but least efficient way to deal with this is to queue up a refresh automatically if the delete operation fails. Correct. But I have to admit that my experience with such full refreshes was always painful. If anything, then rather the "callback" method.

kerem commented

2026-02-25 21:34:19 +03:00

Author

Owner

@jasonmunro commented on GitHub (Aug 21, 2018):

Just updated our ajax logic to allow a request to fire the callback on failure - before this change the callback would be ignored if an ajax request failed. This is required to fix this properly. I was going to then code up some logic to save the modified rows before they change, and on failure determine the correct action to reverse and then insert/update each row (this problem is most noticeable on delete, but effects all message actions). This quickly became ugly and I there are a number of corner cases to deal with.

Instead I'm simply going to:

snapshot the current state of the message list
let the immediate actions occur as they do now
revert the message list to the snapshot if the ajax request failed

It should be much better than attempting a server side refresh of the list, and work with simple logic for all message list views. Should know shortly what the performance is like.

Last thing after that is to fix the error message location on mobile which is proving to be annoyingly difficult to resolve :)

@jasonmunro commented on GitHub (Aug 21, 2018): Just updated our ajax logic to allow a request to fire the callback on failure - before this change the callback would be ignored if an ajax request failed. This is required to fix this properly. I was going to then code up some logic to save the modified rows before they change, and on failure determine the correct action to reverse and then insert/update each row (this problem is most noticeable on delete, but effects all message actions). This quickly became ugly and I there are a number of corner cases to deal with. Instead I'm simply going to: - snapshot the current state of the message list - let the immediate actions occur as they do now - revert the message list to the snapshot if the ajax request failed It should be much better than attempting a server side refresh of the list, and work with simple logic for all message list views. Should know shortly what the performance is like. Last thing after that is to fix the error message location on mobile which is proving to be annoyingly difficult to resolve :)

kerem commented

2026-02-25 21:34:19 +03:00

Author

Owner

@jasonmunro commented on GitHub (Aug 21, 2018):

Just pushed the fix for this and it works quite well IMO! I'm going to close this and create a new ticket for the message location on mobile

@jasonmunro commented on GitHub (Aug 21, 2018): Just pushed the fix for this and it works quite well IMO! I'm going to close this and create a new ticket for the message location on mobile