delete,delete,delete: too fast for back end?

RESOLVED FIXED

Status

RESOLVED FIXED
18 years ago
10 years ago

People

(Reporter: sspitzer, Assigned: naving)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

when I do "delete,delete,delete" on my imap inbox, I get assertions and the
deletes fail.

see bug #47645

here are the assertions:

###!!! ASSERTION: move/copy already in progress: '!m_copyState', file
nsImapMailFolder.cpp, line 5094
###!!! Break: at file nsImapMailFolder.cpp, line 5094
setting next msg view index after delete to 349
###!!! ASSERTION: move/copy already in progress: '!m_copyState', file
nsImapMailFolder.cpp, line 5094
###!!! Break: at file nsImapMailFolder.cpp, line 5094

Is our fe is too fast for the back end?

Comment 1

18 years ago
this is nothing new, and you could get this from the previous tree widget too.
Basically, we're trying to run multiple moves into the trash, and the trash is
asserting that you can only move one message at a time into the trash.

Updated

18 years ago
Summary: delete,delete,delete: to fast for back end? → delete,delete,delete: too fast for back end?
(Assignee)

Comment 2

16 years ago
Created attachment 98342 [details] [diff] [review]
proposed fix

Going through copyService would fix the problem because copyService can handle
multiple requests. Local already goes through copyService.
(Assignee)

Comment 3

16 years ago
Cavin, David. Can I get reviews ? thx

Comment 4

16 years ago
we can't do this until we fix the offline issues with the copy service (using
the copy service completely breaks imap offline)
(Assignee)

Comment 5

16 years ago
*** Bug 74425 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 6

16 years ago
I think now you can review this because offline issue is fixed. 
Status: NEW → ASSIGNED

Comment 7

16 years ago
Comment on attachment 98342 [details] [diff] [review]
proposed fix

sr=bienvenu
Attachment #98342 - Flags: superreview+

Comment 8

16 years ago
Sorry, I'm going to have to ask again that you hold off on this. It turns out
that if anyone doesn't notify the copy service that a copy is completed, all
subsequent attempts to use the copy service fail. So, for example, if an offline
copy fails (I'm still tracking down more bugs there), then everything that uses
the copy service will fail, like copying to the sent folder. If we make delete
use the copy service before fixing those bugs, delete will stop working, even
after you go online. This is making me very nervous about using the copy service
for everything. It used to be that we could get in a situation where copying to
a particular folder would fail when something went wrong, but with the copy
service, now every move/copy/delete will fail. Either we need to track down all
possible failure cases with the copy service, or we need to figure out a way to
make it more robust.

Comment 9

16 years ago
Comment on attachment 98342 [details] [diff] [review]
proposed fix

r=cavin.
Attachment #98342 - Flags: review+
(Assignee)

Comment 10

16 years ago
fix checked in. David's point was fixed in other bug. 
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.