Solved Pop3 download (gmail not involved) broken with latest snapshots
bug only GMAIL
Yes I got the same error:
Meanwhile, I could fix my problem by overwriting the folder .../vivaldi-snapshot/Default/Storage/ext/mpognobbkildjkofajifpdfhcoklimli with an two-week-old folder from my backups.
BUT I still get the error "Cannot destructure..." so this shouldn't be the culprit.
By the way, the affected account is an ionos account - so probably the same technology as your 1und1.
Even so my mails are getting downloaded again, this problem makes me somewhat nervous, because there is no working database repair tool. Just deleting the folder which I replaced leads to an unusable Vivaldi Mail. I also tried to start with a clean profile and imported from a backuped profile path. That wasn't successful at all.
Even so the import tool told me success with importing bookmarks, passwords and history, there was nothing imported. As well, there was no option to import mails from this old profile. This option is shown when you try to import from old opera profile, but not when you want to import from a vivaldi instance.
Not sure, wether the error would not be the culprit or at least be connected with the culprit.
I've also tried resetting the mpognobbkildjkofajifpdfhcoklimli - folder with prior versions older than the last received mails in both accounts.
Vivaldi indicated an update of the mail version in status bar after restart.
This process most likely does something unexpected with the index.
The result for both older versions of the folder contents was the same. One account started downloading msgs again, the other did not. I also still get the error, but only for the non-working account.
I do share your worries regarding the robustness of the mail backend. Some bOrked or orphaned index entry seems to render an account useless without the chance to keep | bring back | import old mail not present on the Pop3 Server as of now it seems. The same for sent mails. Even backups do not resolve the situation. Those would only work with an older version but you can't downgrade.
@mib2berlin FYI, I think this is worth being looked at.
Hi, a developer asked 2 mail developers to take a look a few days ago.
Issue here is reproduction.
I set up a POP3 mail account with a vivaldi.net email address on a version prior to the v186 upgrade.
Then tried to run the upgrade and I didn't run into any issues. Even with pending mail still to come in while not having finished the sync first.
We'll try some more, otherwise we'll need to fine some way of making a blind fix for this...
Edit: Think we found a possible culprit. We'll look into it.
@fuxs Did you see any errors in the log during the upgrade?
Thanks guys for investigating. Glad you found a possible culprit, nevertheless I'll answer your questions as well.
During the upgrade no errors came to view and to the first-hand log (Mail icon in status bar). In console I came across the 'Cannot destructure property' error for the account but nothing else. So, no, no error I think but I could try again.
I'd guess that this cannot be easily reproduced. Both orphaned index entries which cannot be 'destructured' are older ones as of their SearchListIds. Might have been an unsuccessful delete or housekeeping, as they are present somewhere in the index but not in MailDB.
From the outside it looks like Mail quits building up the 'final array' of msg-entries which is checked against the Pop3 server but happily steps in again afterwards, showing the 'finished indexing for' msg in status bar. So to handle the symptom it might be a way to catch the error and just kill this item from the array.
From a deeper and and more cause based perspective it would be great if such glitches in the index could be found und healed by some housekeeping job or a dedicated function to call for the user. I have no idea, how this inconsistency was produced - perhaps also a crash and this might happen inbetween? If so, I'd much more like to heal the inconsistency than to reset the account and loose all msgs not present on the server (incl. sent). And, if a msg is not present in MailDB anymore, it should also not be in the index - why not clean that up.
@fuxs thanks for reporting this. A fix is on the way. This was not a problem with the data itself but with a piece of code which didn't correctly handle a (rather rare but) intact structure of the data.
Great news, @gudmundurg74
Looking forward to verifying the fix.
Fix is out in latest snapshot
Verified, both accounts happily download msgs again. I am pretty much relieved, phew.
Thanks a lot guys!