804904 - [email/IMAP] implement move/trash 'check' implementations (message moves/deletions are never performed on the server in the event of failure or app restart)

Status: RESOLVED WONTFIX

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

Description

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

+++ This bug was initially created as a clone of Bug #799829 +++

Bug 799829 punted on the error-handling 'check' and undoing 'undo' implementations for move and delete/trash operations in the interest of dogfooding expediency.  We still want these implemented in the back-end, but per discussion with :doliver today, we are very likely to remove the UI exposure of the 'undo' operation out of expediency.  This may end up slightly moot, as we may need the 'check' handling depending on how flakey our IMAP connections are, and I think 'undo' may end up just relying on 'check' (at least initially) since we will want to avoid redundant COPY commands.  (And that implies a similar level of complexity to check, at which point, why not have them basically be the same code with a parameter?)

Comment 1

[Mike Connor [:mconnor]]

Blocking flag copied from clone, not blocking on this without much stronger rationale.

Comment 2

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

The impact of not implementing this is that message moves and deletions may not actually occur on the server if either of the following happens:
A) An error occurs while running the operation such as connection loss, disgruntled server, etc.
B) The e-mail app shuts down and is reloaded prior to running the operation.  (When loading the account we mark all operations that have not been run as requiring a check for correctness reasons.  We could lower this cost at the expense of performing more database commits.)  This is most likely to occur if the device is offline for an extended period of time.

Comment 5

[Dylan Oliver [:doliver]]

[priority] --> tracking-b2g:+ conversion

Comment 6

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

I'm removing "undo" from the scope since that's an additional level of complexity (that would also imply UI changes), and the move/delete not really happening as an offline op is a serious limitation/problem.

What I plan to do here is:
- Implement a UIDPLUS fast-path that allows us to avoid having to open the target folder.
- Implement check as a variant on the move operation.  In non-UIDPLUS mode, we check for the presence of the message-id in the target folder before performing the copy.  So for non-check it's "copy, find UID, delete".  For check in the half-completed case it's "find UID, delete."  For check in the not-started case it's "try to find UID but fail, copy, find UID, delete."
- Do the gmail delete/archive specialization proposed on bug 951380.  The rationale for doing this at the same time is that it's actually a fairly simple change, but it's touching the exact same code and the required tests are in the same boat.  Doing the gmail delete as a follow-up would likely result in wasted effort as things potentially would need to be refactored again, etc.

Comment 7

[BMO Automation]

Firefox OS is not being worked on