If you reply to an email, and then quickly archive it, you'll get a "could not read previous flags" error. The message is archived, the reply is sent, but the message being replied to does not get the "replied" flag.
This is a race condition between you archiving it and the message being sent:
- Sending message happens in a separate goroutine from both the worker and the main UI thread. You :send the message.
- Aerc removes display of the tab, sending you back to the message list where you see the message and Archive it.
- The worker archives it, removing it from the maildir
- Meanwhile, sending has finished and a WorkerMessage is sent to mark this message as Answered. But it isn't in the maildir anymore, so there is nothing to mark (and it fails when it tries to get the current Flag list on the message)
I think the cleanest fix is to prevent any action which would remove a message from the directory if it has a pending reply sending. This essentially copies what a :send -a does, but prevents users from accidentally doing this.
Imho, it would be even cleaner to have a proper way to chain commands, although that would probably be harder to develop. See https://todo.sr.ht/~rjarry/aerc/92
On Mon May 08, 2023 at 16:53, ~rockorager wrote:
This is a race condition between you archiving it and the message being sent:
- Sending message happens in a separate goroutine from both the worker and the main UI thread. You :send the message.
- Aerc removes display of the tab, sending you back to the message list where you see the message and Archive it.
- The worker archives it, removing it from the maildir
- Meanwhile, sending has finished and a WorkerMessage is sent to mark this message as Answered. But it isn't in the maildir anymore, so there is nothing to mark (and it fails when it tries to get the current Flag list on the message)
I think the cleanest fix is to prevent any action which would remove a message from the directory if it has a pending reply sending. This essentially copies what a :send -a does, but prevents users from accidentally doing this.
I could get behind this, but in this case it would be cool if we could hide a message when doing :send -a, this way if all goes well, the user does not need to know about what is going on in the background and we could unhide the message if there's an error with sending.
The current behaviour of :send -a is a bit awkward since the message kind of randomly disappears.