MessageNotFound after new mail was sent

[romanofski]

Describe the bug
When I sent an email, the view goes back to the list of threads. When I try to re-open the same message, I get a MessageNotFound error. For example:

MessageNotFound "notmuch-sha1-37d366f6ef51d6b94836805748103ec126d391c8"

To Reproduce
Steps to reproduce the behavior:

1. (Perhaps a custom query needs to be executed first)
2. Compose a new mail from an old mail by opening a thread and pressing e.
3. Sent the mail.
4. Back on the thread view try to open the thread again.

Custom query first:

1. Use a custom query to find a few threads: e.g. to:
2. Start the composition from there

Expected behavior
Not a MessageNotFound error.

Screenshots
None

Additional context
Typically I reload the thread list after going back. Perhaps the keybindings are configured like that too and should be investigated.

[romanofski]

Just checked with composing a new mail from the default query after start up, and the problem doesn't exist once the mail is sent and Purebred went back to the threads view.

[romanofski]

I think it has something to do with the mail being sent, falling into the result list of the search the threadview is set to. For example if the search is to:john and we're sending a new mail to john, the thread list is now obsolete, since the just sent mail isn't included ...

[romanofski]

This one is nasty. The source of the problem is the composeAsNew action, which removes the file path from the notmuch index. I guess that's what we want when dealing with draft mails, since the drafts are getting removed and turned into mails we want to sent. However, not really something we want to do for existing mails, like mails we've sent.

So in this instance, what happens is, that the mail is removed from the index. The mail is composed as new, changed, sent and re-indexed. The view returns to the original query and obviously the original mail we created a new compose from doesn't exist any more.

[frasertweedale]

@romanofski can we handle it in a similar way to how we update tags on the NotmuchMail after editing. But instead of just modifying the selected NotmuchMail on the thread view, we replace it with a new one?

[frasertweedale]

Hm I see the problem... OK here's another idea. The message "key" in libnotmuch is the MessageID. If we write (and index) draft mail with message ID, and keep that message ID the same for composeAsNew, then indexing and removal can just remove files from the libnotmuch message object, rather than removing the message from the notmuch db then adding a new one. Then the same message object previously referred to shall still exist.

Maybe I am misunderstanding the scenario... but let me know what you think.

[romanofski]

It depends really, because for draft mails, we would want to remove them from the index as long as they're sent (I would think?). thinks
With your last comment, perhaps we don't, but rather just change the tags (from draft to sent). Generally speaking just updating the database of the mail. Is that what you meant?

I think my initial mental model was to literally unindex and delete the files. But having the drafts around until the mail is sent is actually a good thing (just to avoid loosing your mail).

[romanofski]

I think the trouble is with the underlying file management and the semantics with the action: use the current mail as a template to compose a new mail.

For drafts, essentially the file path changes. We move the mail from Drafts/new to Sent (if the mail ends up sending). This workflow isn't fully implemented yet, but half way there if we don't discard the composition but keep it as a draft (see #351).

For any other mails, this action should make a copy of the existing mail to create a new composition.

What I'm currently not sure about is whether a single action/keybinding should implicitly figure this out or whether we're better of using two separate actions/keybindings.