Closed
Bug 72322
Opened 23 years ago
Closed 22 years ago
delete,delete,delete: too fast for back end?
Categories
(MailNews Core :: Backend, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: sspitzer, Assigned: naving)
References
Details
Attachments
(1 file)
870 bytes,
patch
|
cavin
:
review+
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
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•23 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•23 years ago
|
Summary: delete,delete,delete: to fast for back end? → delete,delete,delete: too fast for back end?
Assignee | ||
Comment 2•22 years ago
|
||
Going through copyService would fix the problem because copyService can handle multiple requests. Local already goes through copyService.
Assignee | ||
Comment 3•22 years ago
|
||
Cavin, David. Can I get reviews ? thx
Comment 4•22 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 6•22 years ago
|
||
I think now you can review this because offline issue is fixed.
Status: NEW → ASSIGNED
Comment 7•22 years ago
|
||
Comment on attachment 98342 [details] [diff] [review] proposed fix sr=bienvenu
Attachment #98342 -
Flags: superreview+
Comment 8•22 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•22 years ago
|
||
Comment on attachment 98342 [details] [diff] [review] proposed fix r=cavin.
Attachment #98342 -
Flags: review+
Assignee | ||
Comment 10•22 years ago
|
||
fix checked in. David's point was fixed in other bug.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•