Refresh timer being disabled due to an error during mail/index update

[bramadams]

At least once a week, the refresh timer used to automatically check for new emails somehow gets disturbed if an error happens during mail/index update. Since this happens silently, I would only find out hours later that my emails are not up-to-date.

Wrapping the call in `condition-case' better protects against this issue.

[djcb]

Don't quite understand this, wouldn't this raise another error if the condition-case catches one? I.e., I'd expect (error nil).

[bramadams]

That might even be better, or perhaps more explicitly an (error (message "[mu4e] error during automatic update: %s" (error-message-string err))).

The reason the current patch worked in my case, is that I tend to have debug-on-error set to true:

• Without the fix, any transient issue would be thrown up until timer-event-handler, where the condition-case-unless-debug handler would not fire for this error, which is the root of the problem.
• With my suggested fix, the error becomes a user-error, for which debug-on-error is meaningless (see the documentation of user-error in subr.el), hence the handler in timer-event-handler does trigger.
• With your suggestion no error would happen at all, which would be even better.

[bramadams]

I replaced the mu4e-warn by a message instead (so the user knows something's acting up, and they might look into the intermittent issue).

[bramadams]

I've been running emacs for a while without restarting, and somehow the email auto-update functionality stopped working again, even with the above patch. No configuration options were changed, yet somehow something is blocking the automatic update. Manual updating works, but does not re-trigger the auto-update.

Any suggestions why auto-update might stop working? I did not find any obvious error messages.

[djcb]

I've been running emacs for a while without restarting, and somehow the email auto-update functionality stopped working again, even with the above patch. No configuration options were changed, yet somehow something is blocking the automatic update. Manual updating works, but does not re-trigger the auto-update.

Any suggestions why auto-update might stop working? I did not find any obvious error messages

There's a value mu4e--update-timer which holds the timer.

[bramadams]

OK, just checked and its value currently is nil.

Perhaps this pull request should not just log a message (even though I did not find any trace of the message logged by the above patch) but also re-trigger a timer? Not sure what would be the best approach for that.

[bramadams]

In other words, is there a way for the following code from mu4e--pong-handler to be rerun in case the timer becomes nil (presumably due to an error):

(when (and mu4e-update-interval (null mu4e--update-timer))
      (setq mu4e--update-timer
            (run-at-time 0 mu4e-update-interval
                         (defun mu4e--refresh-timer ()
                           (condition-case err
                           (mu4e-update-mail-and-index
                               mu4e-index-update-in-background))))))

[djcb]

In other words, is there a way for the following code from mu4e--pong-handler to be rerun in case the timer becomes nil (presumably due to an error):

(when (and mu4e-update-interval (null mu4e--update-timer))
      (setq mu4e--update-timer
            (run-at-time 0 mu4e-update-interval
                         (defun mu4e--refresh-timer ()
                           (condition-case err
                           (mu4e-update-mail-and-index
                               mu4e-index-update-in-background))))))

My first question would be how mu4e--update-timer could ever become nil without mu4e-quit. Perhaps you can check that, e.g. with M-x debug-on-variable-change?

[bramadams]

OK, thanks, will look into this and will get back once the issue triggers again.

[bramadams]

Seems like the issue has been resolved: debug-on-variable-change showed how mu4e--update-timer was set to nil upon mu4e-quit, but never reinitialized upon a subsequent call to mu4e due to mu4e-trash-folder and mu4e-sent-folder no longer being in sync with my email provider's settings. Just had to update the values of the latter two variables, no need for the PR anymore.