730494 - Message sent successfully, but crash prevents saving copy/deleting draft

Status: RESOLVED INVALID

(Thunderbird :: Message Compose Window, defect)

Description

[Chris Mounce]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Build ID: 20120215223356

Steps to reproduce:

I wrote an email. The email auto-saved to my drafts folder while I was writing it, without me clicking save. I finished editing the email and clicked send.

I don't have steps to reproduce, unfortunately. Most of the time, Thunderbird doesn't crash when I send email. But it has crashed more than once for me, with these same effects. Diagnostic suggestions welcome!


Actual results:

The email was sent successfully. Thunderbird crashed. No copy appeared in my sent folder, even though I have Thunderbird set up to save sent messages. A partial copy (autosave had not saved the last sentence or two) remained in my drafts folder.


Expected results:

No crash. A copy of the message that was actually sent should have been saved to my sent folder. The partial draft should have been deleted from my drafts folder.

Comment 1

[Hashem Masoud]

(In reply to Chris Mounce from comment #0)
Read this: http://kb.mozillazine.org/Breakpad and report the crash ID please.

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to Chris Mounce from comment #0)
> Expected results:
> A copy of the message that was actually sent should have been saved to my sent folder. 
> The partial draft should have been deleted from my drafts folder.

Mail sending consists of;
(1) auto-save or manual save of draft mail
(2) By Send request, pass mail data to SMTP server
(3) After successful send, delete draft
(4) Copy sent mail copy to Sent folder
If System crash, Power failure, Tb's crash happens at a step, process of the step is killed and following steps are not executed.

Are you requesting recovery(redo) of all of (1) to (4) after any crash at any step?

Comment 3

[Chris Mounce]

I'm requesting that TB not crash. :)

I hadn't thought too much about recovery. To me, it doesn't make sense to retry all of them. For example, if TB knows that (2) succeeded, TB should log that, so that if it crashes during (3), it knows that it only has to retry (3) and (4).

I realize that we're trying to bring transactionality to a non-transactional system, and that there are fundamental problems with that. But it seems like we could do a better job of that.

My main concerns are as follows:
(A) I don't know if my message was sent or not. Did TB crash before mail data was sent, or after? Failing before (2) looks exactly the same as failing after (2), and I don't know if I should resend or just wait.
(B) I don't have a record of what I sent. I still have the draft, but it's a partial draft, missing the last couple of sentences. Does this indicate a fault in (1)?
(C) TB's implementation of a central feature (sending email) has a crash bug.

I will attach crash logs, etc, the next time TB does this.

Comment 4

[Chris Mounce]

Crash ID bp-d47152b0-cee6-4f8e-8827-69fa52120302

https://crash-stats.mozilla.com/report/index/d47152b0-cee6-4f8e-8827-69fa52120302

Comment 5

[Wayne Mery (:wsmwk)]

Thanks for the crash ID. This is crashing in Kerberos, not in thunderbird

Comment 6

[Wayne Mery (:wsmwk)]

0	Kerberos	Kerberos@0x6de1	
1	libSystem.B.dylib	mach_msg_server_once	
2	Kerberos	Kerberos@0x7932	
3	Kerberos	Kerberos@0xa7c3	
4	Kerberos	Kerberos@0xdb2f	
5	Kerberos	Kerberos@0xdbf9	
6	Kerberos	Kerberos@0xd74d	
7	Kerberos	Kerberos@0x30912	
8	Kerberos	Kerberos@0x2fb2b	
9	Kerberos	Kerberos@0x2fcb2	
10	Kerberos	Kerberos@0x32caa	
11	Kerberos	Kerberos@0x3ccf1	
12	Kerberos	Kerberos@0x5e8b0	
13	Kerberos	Kerberos@0x68dad	
14	XUL	nsAuthGSSAPI::GetNextToken	extensions/auth/nsAuthGSSAPI.cpp:486
15	XUL	nsAuthSASL::GetNextToken	extensions/auth/nsAuthSASL.cpp:158
16	XUL	nsMsgProtocol::DoGSSAPIStep1	mailnews/base/util/nsMsgProtocol.cpp:898
17	XUL	nsImapProtocol::AuthLogin	mailnews/imap/src/nsImapProtocol.cpp:5681
18	XUL	nsImapProtocol::TryToLogon	mailnews/imap/src/nsImapProtocol.cpp:8336
19	XUL	nsImapProtocol::ProcessCurrentURL	mailnews/imap/src/nsImapProtocol.cpp:1697

Comment 7

[Ludovic Hirlimann [:Usul]]

Might be worth reporting to Apple.

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to Chris Mounce from comment #3)
> I hadn't thought too much about recovery. To me, it doesn't make sense to
> retry all of them. For example, if TB knows that (2) succeeded, TB should
> log that, so that if it crashes during (3), it knows that it only has to
> retry (3) and (4).
> I realize that we're trying to bring transactionality to a non-transactional
> system, and that there are fundamental problems with that. But it seems like
> we could do a better job of that.
> My main concerns are as follows:
> (A) I don't know if my message was sent or not. Did TB crash before mail
> data was sent, or after? Failing before (2) looks exactly the same as
> failing after (2), and I don't know if I should resend or just wait.
> (B) I don't have a record of what I sent. I still have the draft, but it's a
> partial draft, missing the last couple of sentences. Does this indicate a
> fault in (1)?

Tb crash is not only cause of such issues. Power failure/System crash also produces such problems.
To protect user from "loss of sending mail data" or "loss of sent mail copy", improvement like next is needed.
(1) When Send is requested,
    create mail data stream in Pending-Outbox folder(extention of Outbox)
    instead of current \Temp or /tmp directory,
    with X-Mozilla-Sent-Status=Not-sent-yet,
         X-Mozilla-Sent-Mail-Copy-Status=Not-copied-yet
         X-Mozilla-Draft-Delete-Status=Not-deleted-yet,offset/UID of draft
(2) Delete last draft mail. X-Mozilla-Draft-Delete-Status=Deleted-normally.
(3) Send mail to SMTP server.
    After successful send, X-Mozilla-Sent-Status=Sent-normally.
(4) Save sent mail copy to Sent folder.
    After successful save, X-Mozilla-Sent-Mail-Copy-Status=Copied-normally.
(5) Delete the mail in Pending-Outbox.
    => X-Mozilla-Status: 0009 (Expunge bit = On)
(6) If crash occurs at mid of above steps, redo needed steps after restart of Tb.
(7) To avoid exess X-Mozilla-xxx: headers, remove them upon save as .eml, copy/move to other mail folder especially when IMAP folder. 

Pending-Outbox in above context can be current Outbox of "Local Folders". Above can be applied to mail sent by "Send Later", mail sent with "Send in Backgroud".
> http://kb.mozillazine.org/Thunderbird_3.0_-_New_Features_and_Changes#Send_in_Background
> https://wiki.mozilla.org/Thunderbird/TestPlans/SendInBackground

Chris Mounce(bug opener), please open separate bug for such feature, if you think such enhancement is needed for Tb users and is useful for many users.