(In reply to Kai Engert [:KaiE:] from comment #34) > To reproduce: > [...] > - enable "download headers only" > - disable "leave messages on server" [...] > (not sure those are necessary, but that's what we use) Apparently exactly the combination of those two options shows the unwanted behavior: Only in this case https://searchfox.org/comm-central/rev/2cf7d6d45ae722859ec1e5358713c3861ca06a96/mailnews/local/src/Pop3Client.sys.mjs#1592 is called after a body for a partial messages has been fetched, leading eventually to https://searchfox.org/comm-central/rev/2cf7d6d45ae722859ec1e5358713c3861ca06a96/mailnews/local/src/Pop3Client.sys.mjs#1427 where [nsPop3Sink::EndMailDelivery()](https://searchfox.org/comm-central/rev/2cf7d6d45ae722859ec1e5358713c3861ca06a96/mailnews/local/src/nsPop3Sink.cpp#193) is called. This calls [nsPop3Sink::CheckPartialMessages()](https://searchfox.org/comm-central/rev/2cf7d6d45ae722859ec1e5358713c3861ca06a96/mailnews/local/src/nsPop3Sink.cpp#119-123) right away. Unfortunately, this finds all just completed messages already absent from the server and therefore removes them from the database. Anyway, commenting out https://searchfox.org/comm-central/rev/2cf7d6d45ae722859ec1e5358713c3861ca06a96/mailnews/local/src/nsPop3Sink.cpp#194 seems to mitigate the problem. Could you verify this, Kai? For a more robust solution, we should check whether and when both nsPop3Sink::FindPartialMessages() and nsPop3Sink::CheckPartialMessages() are to be called for pop3-js. Furthermore, with "leave messages on server" enabled, nsPop3Sink::EndMailDelivery() is never called. I don't know if that's entirely correct.
Bug 1930847 Comment 40 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Kai Engert [:KaiE:] from comment #34) > To reproduce: > [...] > - enable "download headers only" > - disable "leave messages on server" [...] > (not sure those are necessary, but that's what we use) Apparently exactly the combination of those two options shows the unwanted behavior: Only in this case https://searchfox.org/comm-central/rev/2cf7d6d45ae722859ec1e5358713c3861ca06a96/mailnews/local/src/Pop3Client.sys.mjs#1592 is called after a body for a partial messages has been fetched, leading eventually to https://searchfox.org/comm-central/rev/2cf7d6d45ae722859ec1e5358713c3861ca06a96/mailnews/local/src/Pop3Client.sys.mjs#1427 where [nsPop3Sink::EndMailDelivery()](https://searchfox.org/comm-central/rev/2cf7d6d45ae722859ec1e5358713c3861ca06a96/mailnews/local/src/nsPop3Sink.cpp#193) is called. This calls [nsPop3Sink::CheckPartialMessages()](https://searchfox.org/comm-central/rev/2cf7d6d45ae722859ec1e5358713c3861ca06a96/mailnews/local/src/nsPop3Sink.cpp#119-123) right away. Unfortunately, this finds all just completed messages already absent from the server and therefore removes them from the database. Anyway, commenting out https://searchfox.org/comm-central/rev/2cf7d6d45ae722859ec1e5358713c3861ca06a96/mailnews/local/src/nsPop3Sink.cpp#194 seems to mitigate the problem. Could you verify this, Kai? For a more robust solution, we should check whether and when both nsPop3Sink::FindPartialMessages() and nsPop3Sink::CheckPartialMessages() are to be called for pop3-js. ~Furthermore, with "leave messages on server" enabled, nsPop3Sink::EndMailDelivery() is never called. I don't know if that's entirely correct.~