Re: [Imap-protocol] Strange behavior with Gmail IMAP when using CONDSTORE extension

Jamie Nicolson <[email protected]> Wed, 22 Jul 2015 17:21:00 -0700
Newsgroups gmane.mail.imap.general
Message-ID <CACU8CfRygwG7dL4REXzUtGPYbR_P9ePGzrQkgZuJ1R8uQtd0mg@mail.gmail.com>
--===============5212522356438476714==
Content-Type: multipart/alternative; boundary=bcaec547cbed6fc2eb051b7fde67

--bcaec547cbed6fc2eb051b7fde67
Content-Type: text/plain; charset=UTF-8

This could be a bug. I can't tell from this snippet, but what was the last
modification to happen to the message with UID 207722? Was it the delivery
of the message, marking it as read (STORE +FLAGS \Seen), or something else?

On Wed, Jul 22, 2015 at 4:54 PM, Michael Grinich <[email protected]> wrote:

> Our team has seen the following strange behavior when making requests to
> the Gmail IMAP server. I wanted to share this with the list and Brandon to
> see if folks have ideas for mitigating or fixing the issue, or whether this
> is actually a bug in Gmail's IMAP implementation.
>
> Here's the log:
>
> T2 SELECT "[Gmail]/All Mail"
> * FLAGS (\Answered \Flagged \Draft \Deleted \Seen $Forwarded $Junk
> $NotJunk $NotPhishing $Phishing NotJunk)
> * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen $Forwarded
> $Junk $NotJunk $NotPhishing $Phishing NotJunk \*)] Flags permitted.
> * OK [UIDVALIDITY 11] UIDs valid.
> * 126069 EXISTS
> * 0 RECENT
> * OK [UIDNEXT 208199] Predicted next UID.
> * OK [HIGHESTMODSEQ 14064776]
> T2 OK [READ-WRITE] [Gmail]/All Mail selected. (Success)
> *T3 UID FETCH 207722 (FLAGS) (CHANGEDSINCE 14055062)*
> ** OK [HIGHESTMODSEQ 14064776]*
> ** 125605 FETCH (UID 207722 MODSEQ (14063567) FLAGS (\Answered \Seen))*
> T3 OK Success
> *T4 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 14055062)*
> * 125938 FETCH (UID 208058 MODSEQ (14060020) FLAGS ())
> * 125939 FETCH (UID 208059 MODSEQ (14060011) FLAGS ())
> * 125940 FETCH (UID 208060 MODSEQ (14060028) FLAGS ())
> * 125941 FETCH (UID 208061 MODSEQ (14060000) FLAGS ())
> * 125942 FETCH (UID 208062 MODSEQ (14060036) FLAGS ())
> * 125943 FETCH (UID 208063 MODSEQ (14060000) FLAGS ())
> * 125944 FETCH (UID 208064 MODSEQ (14060000) FLAGS ())
> * 125945 FETCH (UID 208065 MODSEQ (14060003) FLAGS ())
> * 125946 FETCH (UID 208066 MODSEQ (14060037) FLAGS ())
> * 125947 FETCH (UID 208067 MODSEQ (14060043) FLAGS ())
> * 125948 FETCH (UID 208068 MODSEQ (14060000) FLAGS ())
> * 125949 FETCH (UID 208069 MODSEQ (14060045) FLAGS ())
> * 125950 FETCH (UID 208070 MODSEQ (14060000) FLAGS ())
> * 125951 FETCH (UID 208071 MODSEQ (14060025) FLAGS ())
> * 125952 FETCH (UID 208072 MODSEQ (14060011) FLAGS ())
> * 125953 FETCH (UID 208073 MODSEQ (14060045) FLAGS ())
> * 125954 FETCH (UID 208074 MODSEQ (14060044) FLAGS ())
> * 125955 FETCH (UID 208075 MODSEQ (14060003) FLAGS ())
> * 125956 FETCH (UID 208076 MODSEQ (14060040) FLAGS ())
> * 125957 FETCH (UID 208077 MODSEQ (14060011) FLAGS ())
> * 125958 FETCH (UID 208078 MODSEQ (14060044) FLAGS ())
> * 125959 FETCH (UID 208079 MODSEQ (14060025) FLAGS ())
> * 125960 FETCH (UID 208080 MODSEQ (14060044) FLAGS ())
> * 125961 FETCH (UID 208081 MODSEQ (14060036) FLAGS ())
> * 125962 FETCH (UID 208082 MODSEQ (14060037) FLAGS ())
> * 125963 FETCH (UID 208083 MODSEQ (14060003) FLAGS ())
> * 125964 FETCH (UID 208084 MODSEQ (14060037) FLAGS ())
> T4 OK Success
>
>
> Why would "UID FETCH 207722 (FLAGS) (CHANGEDSINCE 14055062)" return
> message 207722, but "UID FETCH 1:* (FLAGS) (CHANGEDSINCE 14055062)"
> wouldn't? Is there any way to catch all messages?
>
> I was able to reproduce this exact IMAP exchange multiple times, so
> there's no way the email could have been expunged within the two FETCHes.
>
> We've seen CONDSTORE-related issues happen on multiple Gmail accounts. The
> only workaround we found is "SEARCH MODSEQ", which didn't have this problem
> in tests. However, it was very slow on Gmail.
>
>
>
> Many thanks,
>
> -- Michael
>
> (I work at Nylas)
>
>
> _______________________________________________
> Imap-protocol mailing list
> [email protected]
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>

--bcaec547cbed6fc2eb051b7fde67
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This could be a bug. I can&#39;t tell from this snippet, b=
ut what was the last modification to happen to the message with UID=C2=A0<s=
pan style=3D"font-size:12.8000001907349px">207722? Was it the delivery of t=
he message, marking it as read (STORE +FLAGS \Seen), or something else?</sp=
an></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, =
Jul 22, 2015 at 4:54 PM, Michael Grinich <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Our team has s=
een the following strange behavior when making requests to the Gmail IMAP s=
erver. I wanted to share this with the list and Brandon to see if folks hav=
e ideas for mitigating or fixing the issue, or whether this is actually a b=
ug in Gmail&#39;s IMAP implementation.=C2=A0<div><br></div><div>Here&#39;s =
the log:=C2=A0</div><div><br></div><div><div>T2 SELECT &quot;[Gmail]/All Ma=
il&quot;</div><div>* FLAGS (\Answered \Flagged \Draft \Deleted \Seen $Forwa=
rded $Junk $NotJunk $NotPhishing $Phishing NotJunk)</div><div>* OK [PERMANE=
NTFLAGS (\Answered \Flagged \Draft \Deleted \Seen $Forwarded $Junk $NotJunk=
 $NotPhishing $Phishing NotJunk \*)] Flags permitted.</div><div>* OK [UIDVA=
LIDITY 11] UIDs valid.</div><div>* 126069 EXISTS</div><div>* 0 RECENT</div>=
<div>* OK [UIDNEXT 208199] Predicted next UID.</div><div>* OK [HIGHESTMODSE=
Q 14064776]</div><div>T2 OK [READ-WRITE] [Gmail]/All Mail selected. (Succes=
s)</div><div><b>T3 UID FETCH 207722 (FLAGS) (CHANGEDSINCE 14055062)</b></di=
v><div><b>* OK [HIGHESTMODSEQ 14064776]</b></div><div><b>* 125605 FETCH (UI=
D 207722 MODSEQ (14063567) FLAGS (\Answered \Seen))</b></div><div>T3 OK Suc=
cess</div><div><b>T4 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 14055062)</b></div=
><div>* 125938 FETCH (UID 208058 MODSEQ (14060020) FLAGS ())</div><div>* 12=
5939 FETCH (UID 208059 MODSEQ (14060011) FLAGS ())</div><div>* 125940 FETCH=
 (UID 208060 MODSEQ (14060028) FLAGS ())</div><div>* 125941 FETCH (UID 2080=
61 MODSEQ (14060000) FLAGS ())</div><div>* 125942 FETCH (UID 208062 MODSEQ =
(14060036) FLAGS ())</div><div>* 125943 FETCH (UID 208063 MODSEQ (14060000)=
 FLAGS ())</div><div>* 125944 FETCH (UID 208064 MODSEQ (14060000) FLAGS ())=
</div><div>* 125945 FETCH (UID 208065 MODSEQ (14060003) FLAGS ())</div><div=
>* 125946 FETCH (UID 208066 MODSEQ (14060037) FLAGS ())</div><div>* 125947 =
FETCH (UID 208067 MODSEQ (14060043) FLAGS ())</div><div>* 125948 FETCH (UID=
 208068 MODSEQ (14060000) FLAGS ())</div><div>* 125949 FETCH (UID 208069 MO=
DSEQ (14060045) FLAGS ())</div><div>* 125950 FETCH (UID 208070 MODSEQ (1406=
0000) FLAGS ())</div><div>* 125951 FETCH (UID 208071 MODSEQ (14060025) FLAG=
S ())</div><div>* 125952 FETCH (UID 208072 MODSEQ (14060011) FLAGS ())</div=
><div>* 125953 FETCH (UID 208073 MODSEQ (14060045) FLAGS ())</div><div>* 12=
5954 FETCH (UID 208074 MODSEQ (14060044) FLAGS ())</div><div>* 125955 FETCH=
 (UID 208075 MODSEQ (14060003) FLAGS ())</div><div>* 125956 FETCH (UID 2080=
76 MODSEQ (14060040) FLAGS ())</div><div>* 125957 FETCH (UID 208077 MODSEQ =
(14060011) FLAGS ())</div><div>* 125958 FETCH (UID 208078 MODSEQ (14060044)=
 FLAGS ())</div><div>* 125959 FETCH (UID 208079 MODSEQ (14060025) FLAGS ())=
</div><div>* 125960 FETCH (UID 208080 MODSEQ (14060044) FLAGS ())</div><div=
>* 125961 FETCH (UID 208081 MODSEQ (14060036) FLAGS ())</div><div>* 125962 =
FETCH (UID 208082 MODSEQ (14060037) FLAGS ())</div><div>* 125963 FETCH (UID=
 208083 MODSEQ (14060003) FLAGS ())</div><div>* 125964 FETCH (UID 208084 MO=
DSEQ (14060037) FLAGS ())</div><div>T4 OK Success</div><div><br></div><div>=
<br></div><div>Why would &quot;UID FETCH 207722 (FLAGS) (CHANGEDSINCE 14055=
062)&quot; return message 207722, but &quot;UID FETCH 1:* (FLAGS) (CHANGEDS=
INCE 14055062)&quot; wouldn&#39;t? Is there any way to catch all messages?<=
/div><div><br></div><div>I was able to reproduce this exact IMAP exchange m=
ultiple times, so there&#39;s no way the email could have been expunged wit=
hin the two FETCHes.</div><div><br></div><div>We&#39;ve seen CONDSTORE-rela=
ted issues happen on multiple Gmail accounts. The only workaround we found =
is &quot;SEARCH MODSEQ&quot;, which didn&#39;t have this problem in tests. =
However, it was very slow on Gmail.</div></div><div><br></div><div><br></di=
v><div><br></div><div>Many thanks,</div><div><br></div><div>-- Michael=C2=
=A0</div><div><br></div><div>(I work at Nylas)</div><div><br></div></div>
<br>_______________________________________________<br>
Imap-protocol mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]=
n.edu</a><br>
<a href=3D"http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol=
" rel=3D"noreferrer" target=3D"_blank">http://mailman13.u.washington.edu/ma=
ilman/listinfo/imap-protocol</a><br></blockquote></div><br></div>

--bcaec547cbed6fc2eb051b7fde67--

--===============5212522356438476714==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
--===============5212522356438476714==--