In fact, sometimes I have to click Discard several times to get through a series of such dialogs before Geary will exit.

One possibility is that composers are getting "lost", being hidden instead of being closed when changing conversations or folders.  If you notice cases where you're not prompted about closing a composer when you should be, please note it here.

I still see this bug all the time - several times per day at least.  Unfortunately I still have no reproducible case.

Are you guys seeing this too?  If you'd like to add debug logging that could help pinpoint the problem, I'd be happy to run with logging on and send you the log the next time I see this.

I did see this today.  I don't know what I did to trigger it.  I just now tried a few simple test cases to repro it (create a new message + exit, reply + exit, new message + change folder, etc.) to no avail.

I do recall seeing this before, but the problem is, we were seeing this during the development of the inline composer and Robert fixed the more egregious cases.  I don't recall if I saw this happen after the final patches landed.

Robert, if you can think of some debugging that might help here, please feel free to commit them to master for Adam.

I haven't seen this problem, but I'll keep an eye out.  I'm worried that there's an asynchronous close that isn't actually finishing, leaving us with a composer hanging around that we thought got closed.

Perhaps we can add a little debugging display that shows the number of open composers being tracked, so we can try to see when it diverges from the number that we see.

I've added two debug statements that should print when composers are created and destroyed.  You can check that you get the destroy message whenever you close a composer (whether saved, discarded, or sent).  If you can figure out when you don't get that message, then we can track down where the composer is getting lost.

OK.  Do you recommend that I run Geary with --debug, or with some of the --log options (which?)

--debug is all you need to do.

I've found a way that composers can get lost, although I get the discard message dialog when switching conversations:

When we're indexing the conversations after opening Geary, the UI semi-freezes.  Notably, no composers show up when you reply to a message, but they are actually created.  If you switch conversations before the indexing ends, you get the large spinner.  When the indexing end, we end up in a confused state.  I had opened two composers in a test -- the first popped up, but I got two close dialogs when I tried to get rid of it.

Gah.  The problem is the re-indexing causes the database to lock out all other transactions.  What's probably happening is the composer is performing some async I/O (i.e. opening the Drafts folder), the async request hangs in limbo, then the composer is destroyed before being presented.

If everything else is working (knock on wood), a Cancellable should be set to cancelled when the user changes conversations.  Presumably the composer could monitor that Cancellable as well and use that to tear down properly.  At least, that's my initial though process on all this.

I believe the long database pause at startup is vanquished in master (bug #725929).  Does that solve this problem?  Even if it does, we may be just hiding the underlying issue, or at least making it more difficult to be triggered.

I haven't seen this occur in quite a while now, actually.

Robert, correct me if I'm wrong, but you found a couple of code paths after Adam reported this that could trigger this bug.  (Archive when a composer is open, or something like that?)  So it could be that the problem Robert described in comment #9 is the last way to trigger this.

The archiving bug is still open at bug #730606.  And I suspect there may be ways to get composers lost in the drafts folder, given bug #739141.  So I wouldn't prepare the victory party quite yet.

I haven't seen this since the draft management reworking went in for 0.12, so I'm going to resolve this as fixed. Do reopen it if you see it again.