1065247 - Delete message doesn't work

Status: RESOLVED DUPLICATE of bug 1116694

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Hubert Figuiere [:hub]]

Flame 2.0 BuildID 20140908000202

Gaia f02a8e4e

When I try to delete an email on my personal email (hosted on Dreamhost), it doesn't work. IMAP.

STR:

- view message
- tap delete
- See the message is gone from the list
- Sync
- The message is back

Expected
- Message be gone.


I work fine on my Moz account (Zimbra)

Comment 1

[Hubert Figuiere [:hub]]

It doesn't matter if it is over 3G (cell data) or wifi.

Network works fine.

Delete works fine in K-9 Mail on Android, or Thunderbird on Linux.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Can you provide a logcat a la https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo?  That should help us quickly identify what is going wrong.  The fact that the message disappears from the local list means that it's not a mutex problem and we probably have identified a trash folder.  Thanks!

Comment 3

[Hubert Figuiere [:hub]]

This phone doesn't have ADB enabled. This is NOT a development phone.

Comment 4

[Hubert Figuiere [:hub]]

will get to that in a bit.

Comment 5

[Hubert Figuiere [:hub]]

Attachment: email-log

email log as requested.

Comment 6

[Hubert Figuiere [:hub]]

Also worth noting that I got notification of "new mails" from August..... just now.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

Thanks very much for the log.  I understand they can be a hassle to retrieve, especially when you're actively dogfooding (props!).

Inference from the log indicates that the delete operation is straight-up failing somehow:
09-10 13:54:44.230 I/Gecko   (15154): WLOG: runOp(check: {"type":"delete","longtermId":"0/6d","lifecycle":"do","localStatus":"done","serverStatus":"checking","tryCount":5,"humanOp":"delete","messages":[{"date":1410371)
09-10 13:54:44.230 I/Gecko   (15154): WLOG: runOp_end(check: {"type":"delete","longtermId":"0/6d","lifecycle":"do","localStatus":"done","serverStatus":"checking","tryCount":5,"humanOp":"delete","messages":[{"date":1410371)

Since I have some dreamhost accounts and the log has made it clear that this isn't a secondary failure but a direct failure, I'll try to repro this on my accounts and see what's what and whether this affects us on v2.1 and what we can do for v2.0.

:hub, can you confirm which dreamhost cluster you're on?  I'm on sub4.mail.dreamhost.com and it'd be good to know if you use the same cluster or not.


(In reply to Hubert Figuiere [:hub] from comment #6)
> Also worth noting that I got notification of "new mails" from August.....
> just now.

Dreamhost had some bad mail queue issues in August.  It's possible you're actually seeing these only be delivered now.  We use the INTERNALDATE rather than the date a message claims it was composed, so while in Thunderbird the messages will secretly and quietly end up in the past, we tell you the truth.

Comment 8

[Hubert Figuiere [:hub]]

I am on sub3.mail.dreamhost.com

And no these mails had been delivered and read a while ago. Also one was on the Mozilla account. It was not queue problem.

Comment 9

[Hubert Figuiere [:hub]]

Just to be clear. The Notification date was August as well.

Comment 10

[apropostech]

I can confirm that this is still an issue in 2.1 but only able to reproduce if I select several messages to delete. The messages are copied to trash mailbox but not removed from inbox. The issue is happening whenever a message is moved to another folder and not only for trash, i.e. the message is copied to the destination folder but not removed from original folder on the server. The messages do disappear until next sync however.

Comment 11

[André Fiedler]

maybe a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1116694 and of https://bugzilla.mozilla.org/show_bug.cgi?id=1072322

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

Indeed, now believed to be bug 1116694, particularly the UIDPLUS aspect.  Note that the fix won't be in v2.2 nightly builds until tomorrow.  v3.0 already has the fix.