Bug 259214 - Bad commands sent to the server after sending email [Exchange]
Summary: Bad commands sent to the server after sending email [Exchange]
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: IMAP resource (show other bugs)
Version: 1.4.80
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Kevin Ottens
URL:
Keywords:
Depends on:
Blocks: 264266
  Show dependency treegraph
 
Reported: 2010-12-08 14:49 UTC by Thiago Macieira
Modified: 2011-08-03 10:07 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thiago Macieira 2010-12-08 14:49:11 UTC
Version:           1.4.80 (using Devel) 
OS:                Linux

After I've sent an email, the IMAP resource uploads the email just sent to the "Sent Items" folder. However, it sends some bad commands afterwards:

IMAP log:
S: A000519 OK APPEND completed.
C: A000520 SELECT "Sent Items"
S: * 4683 EXISTS
S: * 1 RECENT
S: * FLAGS ( \Seen \Answered \Flagged \Deleted \Draft $MDNSent )
S: * OK Permanent flags [ PERMANENTFLAGS ( \Seen \Answered \Flagged \Deleted \Draft $MDNSent )  ]
S: * OK UIDVALIDITY value [ UIDVALIDITY 555  ]
S: * OK The next unique identifier value [ UIDNEXT 8452  ]
S: A000520 OK SELECT completed. [ READ-WRITE  ]
C: A000521 UID SEARCH NEW UID 8451:*
S: * SEARCH
S: A000521 OK SEARCH completed.
C: A000522 UID STORE  FLAGS (\Seen $SENT)
S: A000522 BAD Command Argument Error. 11

The new message got UID 8451, but the server didn't report it in the APPEND command. The SEARCH command returned 0 results.

The bad command is the UID STORE one, which forgets to pass the UID to the server (probably because of the 0 results in SEARCH). Note the two spaces between STORE and FLAGS.

Reproducible: Always




OS: Linux (i686) release 2.6.35.2-server-1mnb
Compiler: gcc
Comment 1 Thiago Macieira 2011-01-25 17:46:06 UTC
Probably causes bug 264266.
Comment 2 Allen Winter 2011-04-11 16:11:04 UTC
adding as a showstopper
Comment 3 Volker Krause 2011-04-21 17:28:31 UTC
Git commit 34f1b3e879fff83f6fdc665afea1060d7d411bdd by Volker Krause.
Committed on 21/04/2011 at 11:18.
Pushed by vkrause into branch 'master'.

Recover from unknown UID after APPEND or COPY.

Currently, if unable to determine the UID of a message after an APPEND or
COPY command, we abort the task and leave the Akonadi item with an empty
RID. During the next sync, the message we added to the server is discovered
and downloaded, duplicating it locally. Items with empty RIDs are protected
against deletion during a sync, since they are assumed to not be on the
server yet. This is a safety feature, but gets in to the way of automatic
recovery here.

So, this patch fixes this by assigning an arbitrary random RID in this
case. Note that this only happens if all UID detection attempts fail, not
if e.g. the actual APPEND or COPY failed. Assuming that those commands
report errors correctly, this should be safe.

BUG: 264266
CCBUG: 259214
REVIEW: 101147

M  +12   -10   resources/imap/additemtask.cpp     
M  +10   -8    resources/imap/moveitemtask.cpp     
M  +14   -0    resources/imap/tests/testadditemtask.cpp     
M  +28   -0    resources/imap/tests/testmoveitemtask.cpp     

http://commits.kde.org/kdepim-runtime/34f1b3e879fff83f6fdc665afea1060d7d411bdd
Comment 4 Stephen Kelly 2011-04-22 13:07:54 UTC
Please retest this. It will likely be re-classified as not as release blocker
if no one re-confirms it.
Comment 5 Thiago Macieira 2011-04-26 17:23:46 UTC
Looks like it's fixed. I cannot see the bad commands anymore.