There's various of these already but all i could find are either old or using imap so opening this new one. I can "relatively often" reproduce this when deleting email. I have to go to akonadiconsole and remove it from there otherwise kmail will have a ghost entry forever. Not sure if it's any useful but enabling the debugger in akonadi console gets me this output akonadi_maildir_resource_0: akonadi_maildir_resource_0 (0x564c74f97aa0) 7334 Command: FetchItems scope: UID 320566 scopeContext:ScopeContext(empty) fetchScope:FetchScope( Fetch Flags:QFlags(0x1|0x10|0x20|0x40|0x80|0x100|0x200) Tag Fetch Scope:QSet() Changed Since:QDateTime(Invalid) Ancestor Depth:All ancestors Requested Parts:QVector()) akonadi_maildir_resource_0 (0x564c74f97aa0) 7334 Response: FetchItems Error code: 0 Error msg: id: 320566 parentId: 56 remoteId: remoteRevision: gid: size: 9309 mimeType: message/rfc822 mTime: QDateTime(2018-02-03 11:48:14.000 UTC Qt::TimeSpec(UTC)) flags: QVector() tags: QVector() virtualReferences: QVector() relations: QVector() ancestors: QVector(id:56 remoteId:frameworks name: attributes:QMap() , id:46 remoteId:kde name: attributes:QMap() , id:5 remoteId:/home/tsdgeos/.local/share/local-mail name: attributes:QMap() , id:0 remoteId: name: attributes:QMap() ) parts: QVector() cachedParts: QVector() revision: 0 akonadi_maildir_resource_0 (0x564c74f97aa0) 7334 Response: FetchItems Error code: 0 Error msg: id: -1 parentId: -1 remoteId: remoteRevision: gid: size: 0 mimeType: mTime: QDateTime(Invalid) flags: QVector() tags: QVector() virtualReferences: QVector() relations: QVector() ancestors: QVector() parts: QVector() cachedParts: QVector() revision: -1 akonadi_maildir_resource_0 (0x564c74f97aa0) 7335 Command: Transaction mode: 1 akonadi_maildir_resource_0 (0x564c74f97aa0) 7335 Response: Transaction Error code: 0 Error msg: akonadi_maildir_resource_0 (0x564c74f97aa0) 7336 Command: ModifyItems notify: true noResponse: false invalidateCache: false dirty: true oldRevision: 0 modifiedParts: QFlags(0x40|0x80|0x1000) items: UID 320566 removedFlags:QSet() flags:QSet() addedFlags:QSet() gid: tags:Invalid scope addedTags:Invalid scope removedTags:Invalid scope remoteId: remoteRevision: itemSize:0 removedParts:QSet() parts:QSet() attributes:QMap() akonadi_maildir_resource_0 (0x564c74f97aa0) 7336 Response: ModifyItems Error code: 1 Error msg: [LRCONFLICT] Resource akonadi_maildir_resource_0 tries to modify item 320566 () (in collection 56) with dirty payload, aborting STORE. id: -1 modificationDateTime: QDateTime(Invalid) newRevision: 0 akonadi_maildir_resource_0 (0x564c74f97aa0) 7337 Command: Transaction mode: 3 akonadi_maildir_resource_0 (0x564c74f97aa0) 7337 Response: Transaction Error code: 0 Error msg: akonadiconsole: akonadiconsole-476707713 (0x564c74fc2cf0) 35 Command: FetchItems scope: UID 320566 scopeContext:ScopeContext(empty) fetchScope:FetchScope( Fetch Flags:QFlags(0x4|0x8|0x10|0x20|0x40|0x100|0x200|0x800) Tag Fetch Scope:QSet() Changed Since:QDateTime(Invalid) Ancestor Depth:No ancestor Requested Parts:QVector(PLD:RFC822)) akonadiconsole-476707713 (0x564c74fc2cf0) 35 Response: FetchItems Error code: 1 Error msg: Unable to fetch item from backend (collection -1) : Unable to retrieve item from resource: [LRCONFLICT] Resource akonadi_maildir_resource_0 tries to modify item 320566 () (in collection 56) with dirty payload, aborting STORE. id: -1 parentId: -1 remoteId: remoteRevision: gid: size: 0 mimeType: mTime: QDateTime(Invalid) flags: QVector() tags: QVector() virtualReferences: QVector() relations: QVector() ancestors: QVector() parts: QVector() cachedParts: QVector() revision: -1 I'll try to keep myself from deleting this ghost email for a while in case more debugging is needed, but not sure i'll manage :D I'd be happy enough if you could "force delete" this from kmail without having to resort to akonadiconsole.
I get this bug very regularly. How to use akodaniconsole to delete the ghost email? I really miss the simpler times of kmail 1. The akodani framework has only brought me complications without any apparent useful feature.
(In reply to Anguo from comment #1) > I get this bug very regularly. > How to use akodaniconsole to delete the ghost email? akonadiconsole->browser->find ghost email->right click->delete item You'll recognize the ghost email because clicking on it says " "Unable to fetch item from backend" on the terminal you started akonadiconsole. > > > I really miss the simpler times of kmail 1. The akodani framework has only > brought me complications without any apparent useful feature. You should have omitted this part, it doesn't give any important information and only creates negativity.
I get this message a couple of times every week like: Unable to fetch item from backend (collection -1) : Unable to retrieve item from resource: [LRCONFLICT] Resource akonadi_maildir_resource_0 tries to modify item 5831 () (in collection 19) with dirty payload, aborting STORE. Perhaps the info is important that I am using POP3. The version of akonadi is: 5.11.3 on Fedora 31.
I suggest that this bug should be classified as a serious bug, because I lose every day a lot of emails. This bug should be fixed as soon as possible.
Can someone please respond?
Created attachment 131921 [details] akonadiserver log (from .xsession-errors)
Hello I'm on debian sid and I'm still seeing this bug with: Kontact/Kmail 5.14.1 (20.04.0) KDE Frameworks 5.70.0 Qt 5.14.2 POP3 email account. I've just attached a log from akonadi. The bad thing for me now is that this bug makes akonadiserver crash. This brings some inconveniences like it's not brought up again automatically and you cannot go on with the kmail usage. Some other times the mysql server (the backend I use) is bring up again, so there are 2 mysql sessions which leads to akonadiserver annoyance as it cannot handle the situation. You would need to stop akonadi server, kill all the mysql instances and start akonadiserver again. The problem is reproduced here quite often as the ghost email (wherever it is) is not being dealt. Let me know if I can provide more information.
I still get this message often (see comment 3). KMail version 5.15.3 (20.08.3). Operating System: Fedora 33 KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.10.16-200.fc33.x86_64 OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4770T CPU @ 2.50GHz Memory: 7.2 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600
The bug still exists on Fedora 34, KMail 5.16.2, Akonadi 5.16.2 (20.12.2). Can someone please take a look at this bug?
As far as I can see, this bug effects only "subfolders" of the "local folder". I have set up some filter. After new e-mails are sorted to the "subfolders", many of them appear twice. Click on the first one shows an empty e-mail (this is wrong) and the second shows the new e-mail correct. When I click on the first e-mail again I get the message in the status bar: Unable to fetch item from backend .... with dirty payload It doesn't happen on my "inbox". So I think it is affected to the "subfolders" and has something to do with filters.
Could you please, confirm if this is a dupe of https://bugs.kde.org/show_bug.cgi?id=434706 In order to confirm, you would need to use mariadb/mysql client and check out the transaction status are described in there. Regards,
Thank you for your quick reply. I would like to confirm if this is a dupe of https://bugs.kde.org/show_bug.cgi?id=434706, but to be honest I don't know how. The description in there is not detailed enough to me. Sorry I am a user. Could you please give me in short form the instruction? I am very interested in a fix for this bug and would like to provide the information you need.
(In reply to Raúl from comment #11) > Could you please, confirm if this is a dupe of > https://bugs.kde.org/show_bug.cgi?id=434706 > > In order to confirm, you would need to use mariadb/mysql client and check > out the transaction status are described in there. > > Regards, Hi Raúl, can you please response to my comment #12. I would like to confirm if I know how. One thing I would like to mention and please don't get me wrong. This bug has been reported since more than 3 years. KMail doesn't work properly for pop3-accounts. For example I have deleted a couple of new emails. They were marked as read but not deleted and after 10 or more seconds they were really deleted and gone from my inbox. Some messages came up with "Please wait ..." inbetween. Regards
Attila, sorry for the delay in answering. I'm not a KDE developer but I can explain you what I suspect about this bug and how it can be related (if not duped) to https://bugs.kde.org/show_bug.cgi?id=434706. kontact/akonadi is a user fronted which shows data that those get from akonadi which, in turn, is closely bounded to a database. The database is made up of tables and registers. You can take a look at those tables and registers using an external database browser or the database command line client. For instance, in my case akonadi relies on mariadb database engine and I can query the akonadi data externally like this: ``` $ mariadb -S/run/user/1001/akonadi/mysql.socket MariaDB [(none)]> use akonadi; MariaDB [akonadi]> show tables ; +----------------------------------+ | Tables_in_akonadi | +----------------------------------+ | collectionattributetable | | collectionmimetyperelation | | collectionpimitemrelation | | collectiontable | | flagtable | | mimetypetable | | parttable | | parttypetable | | pimitemflagrelation | | pimitemtable | | pimitemtagrelation | | relationtable | | relationtypetable | | resourcetable | | schemaversiontable | | tagattributetable | | tagremoteidresourcerelationtable | | tagtable | | tagtypetable | +----------------------------------+ 19 rows in set (0.001 sec) ``` kontact/kmail sends database queries to feed akonadi database and also to retrieve data. I think either the query flow or the database engine has some kind of bug or limitation. Hence one of the database queries locks some database tables (like those listed above) and therefore most of the database operations are locked (they cannot be completed). https://bugs.kde.org/show_bug.cgi?id=434706 explains some similar behavior and that is why I asked you to check if both reports are about the same problem. You are right that https://bugs.kde.org/show_bug.cgi?id=434706 is too technical and this is where you could get lost. In order to check whether the problem is the same or not, here is the list of actions that you can perform to verify: * Wait for the problem to reproduce or reproduce it yourself (if possible) * Check `journalctl -xe` output and look for recent output like this: ``` kmail[1317]: org.kde.pim.akonadicore: Received response with a different tag! akonadi_maildispatcher_agent[1586]: void SendJob::setFrom(const QString &from) "mail@milianw.de" akonadi_maildispatcher_agent[1586]: d->m_returnPath "<mail@milianw.de>" akonadiserver[1305]: org.kde.pim.akonadiserver: QueryBuilder::exec(): database reported transaction deadlock, retrying transaction akonadiserver[1305]: org.kde.pim.akonadiserver: "Deadlock found when trying to get lock; try restarting transaction QMYSQL3: Unable to execute statement" akonadi_imap_resource[1583]: org.kde.pim.imapresource: "Connection to server lost." ``` * Additionally you can connect to the mariadb socket: `mariadb -S/run/user/1001/akonadi/mysql.socket` (1001 is your user code, maybe it's a different number) * Issue the following db engine query: `SHOW ENGINE INNODB STATUS` you should see that there is a deadlock detected: *LATEST DETECTED DEADLOCK* section in the https://bugs.kde.org/show_bug.cgi?id=434706 bug If you find out the same outcome, this and the other bug are quite possibly a duplicated. One additional comment is that I think the bug is not specifically about kmail, but about akonadi and its database engine usage. For getting a fix, we would need that someone with enough akonadi and DB knowledge to analyze and find out possible solutions. Unfortunately that is not by my hand. Regards,
Hi Raúl, thank you very much for your explanation. That was very helpfull. I can see in the log a line like: "Deadlock found when trying to get lock; try restarting transaction QMYSQL3: Unable to execute statement" "SHOW ENGINE INNODB STATUS" throws me lines out (see also attachments): LATEST DETECTED DEADLOCK ------------------------ 2021-12-07 08:24:45 0x7fde283ff640 *** (1) TRANSACTION: TRANSACTION 4390340, ACTIVE 0 sec starting index read mysql tables in use 6, locked 6 Regards
Created attachment 144296 [details] Journalctl Akonadi
Created attachment 144297 [details] SHOW ENGINE INNODB STATUS
Created attachment 144299 [details] Journalctl Akonadi timeout writing into stream Here is another example. This time with: "org.kde.pim.akonadiserver: NotificationSubscriber for "MailFilterItemMonitor - 94414111761152" : timeout writing into stream"
Hello: I think here we are talking about 2 different issues: * Issue reported which is that it is not possible to fetch a specific email from akonadi backend. I think this is related to database engine, database corruption or akonadiserver lack of sync with database. This is what your latest journalctl log (https://bugs.kde.org/attachment.cgi?id=144299) could be related to (or maybe not. I'm not sure) * A permanent deadlock in either the communication from akonadi with the database engine or a problem in the database handling. This is exposed when sending the `show engine innodb status;` sql statement to the database engine. This is also exposed with the error message ` Deadlock found when trying to get lock; try restarting transaction QMYSQL3: Unable to execute statement` I think this problem should be followed up in the proper bug report https://bugs.kde.org/show_bug.cgi?id=434706 This problems prevents going on in the kmail usage as akonadi cannot properly fetch or handle data from database. One workaround for my is killing the mariadb server and letting akonadi to restart it. Regards,
Created attachment 144382 [details] Journalctl Index is not within range Hi, @Raúl: Thanks again for your thoughts in comment #19. A litte warning window came up today with the message: "Please wait for the message to be transmitted." I can wait for hours and the window will not disappear. I have to click on "Cancel". Today I have discovered some new lines from journalctl: akonadi_maildir_resource[3184]: org.kde.pim.libmaildir: Maildir::readEntry unable to find: "1638978596336.R472.myhostname:2,S" and kmail[3087]: kf.xmlgui: Index 415 is not within range (0 - 21 ) Sure "Index 415 is not within range (0 - 21 )" but how can this happen? What a nasty bug, isn't it? Regards
Created attachment 144419 [details] Journalctl Akonadi Failed to open external payload Here is some more: akonadi_indexing_agent[3259]: org.kde.pim.akonadicore: Failed to open external payload: "/home/aerdelyi/.local/share/akonadi/file_db_data/62/731662_r0" "No such file or directory"
This bug is unfortunately not fixed. I see every day the message "Unable to fetch item from backend ..." on Fedora 35. There is some more weird behaviour. Let's say I delete 20 new e-mails one after the other (click on the icon "delete"), then this e-mails are still marked as new mails. After that I click on the same 20 e-mails one after the other, then they are marked as read. After that I click on the same 20 e-mails one after the other, then they are finally deleted. So sorry to say, but this bug is pretty annoying and a bad user experience. Can someone please inspect this bug and fix it?
This bug is still not fixed. KMail on Fedora 36 with pop3 is pretty bugy. I guess it has something to do with the "filter" function. I have a setup with very simple filter rules. The filter takes a very long time to apply the rules and sort the new emails into the correct subfoleder. My experience is not to touch KMail while the filter function processing new emails. The filter is pretty slow and takes 5 to 10 minutes for let's say 100 emails. The filter sort sometimes a new email twice into the subfolder. One is readable and the other is empty. Sometimes when I click on a new email, the email is still marked as new and sometimes I have to click 3 times on delete to delete an email and I see many times the popup "Please wait for the message to be transmitted". All this is really frustrating. Can someone please take a look?
I confirm this bug is present.
I was curious and wanted to see how long KMail takes to get the job done when the popup window appears with "Please wait for the message to be transmitted". I gave it up after 4 hours and pressed the "Cancel" button. I hate to say but this is super frustrating. By the way an attachment, to show greyed out lines for new email which are already deleted. This lines are not accessible.
Created attachment 153936 [details] Greyed out line for new email
*** Bug 445747 has been marked as a duplicate of this bug. ***
org.kde.pim.akonadiserver: Handler exception when handling command FetchItems on connection kontact-1880334420 (0x55a90f8389c0) : Unable to fetch item from backend (collection -1) : Unable to retrieve from resource: [LRCONFLICT] Resource Resource akonadi_ews_resource_2 tries to modify item 75080 () (in collection 743) with dirty payload, aborting STORE. I can see collection 743 in Akonadi Console but there is no item 75080 in it.
Also, Akonadi reports 30 elements present in collection 739 but it shows only 4 items in the collection.
KMail version 5.22.0 (22.12.0) has been released for Fedora 36. No changes, the bug is still present. Operating System: Fedora Linux 36 KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Graphics Platform: X11
KMail version 5.23.1 (23.04.1) has been released for Fedora 38. No changes, the bug is still present. Operating System: Fedora Linux 38 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 Graphics Platform: X11
I get a plenty of messages like "Item query returned empty result set". It doesn't matter how many times I click on these new mails, they remain marked as new mail. I hate to say but KMail is not suitable for daily use.
KMail version 5.24.1 (23.08.1) has been released for Fedora 38. No changes, the bug is still present. I get a plenty of messages like "Unable to fetch item from backend (collection -1): Unable to retrieve item from resource: [LRCONFLICT] Resource akonadi_maildir_resource_0 tries to modify item 319216 () (in collection 24) with dirty payload, aborting STORE".
KMail version 5.24.3 (23.08.3) has been released for Fedora 38. No changes, the bug is still present. I get a plenty of messages like "Unable to fetch item from backend (collection -1): Unable to retrieve item from resource: [LRCONFLICT] Resource akonadi_maildir_resource_0 tries to modify item 319216 () (in collection 24) with dirty payload, aborting STORE".