Mail reception stops after some time

[alappe]

Dear Simon,

I have an issue with mail reception stopping after some time. I see no error, but new mails are not picked up any more. Is there a way (e.g. via interactive shell) to mark a mail as unread again to pick it up after I restart the app?

Best regards
Andreas

[JoaoSetas]

Hi Andreas,

I encountered similar issues. While I'm not sure how to retrieve previous emails, I noticed that when the process crashes and doesn’t restart properly, it can sometimes be explained by the following scenario:

yugo/lib/yugo/client.ex

Lines 146 to 155 in bdcb497

	{:ok, socket} =
	if args[:tls] do
	:ssl.connect(
	args[:server],
	args[:port],
	ssl_opts(args[:server], args[:ssl_verify])
	)
	else
	:gen_tcp.connect(args[:server], args[:port], @common_connect_opts)
	end

Sometimes a connection attempt returns {:error, :econnrefused}, causing the process to crash and then restart many times until the Application supervisor shuts it down permently. This can happen, for example, when the IMAP server is down or unreachable. I managed to address this by adding Yugo.Client to a supervisor with the options max_restarts: 100 and max_seconds: 3.

In Application.ex:

def start(_type, _args) do
  children = [
    {DynamicSupervisor,
     name: Myapp.DynamicSupervisor, strategy: :one_for_one, max_restarts: 100, max_seconds: 3}
  ]

  opts = [strategy: :one_for_one]
  Supervisor.start_link(children, opts)
end

Then, when starting the client:

DynamicSupervisor.start_child(
  Myapp.DynamicSupervisor,
  {Yugo.Client,
   name: client_name, module: module, server: server, username: username, password: password}
)

Basically, for the supervisor to permanently shut down Yugo.Client, the process must have more than 100 restarts within 3 seconds. I’m not sure if these are the optimal settings, but tweaking these values might help prevent a permanent shutdown.

[bkono]

I've taken a slightly different approach to addressing it. On my fork I have a branch where I've tweaked the exit handling a hair here to avoid the :normal exit flow. This lets a supervisor be added that can use restart :permanent and :rest_for_one between the connection and any subscribers. Here's an example gist showing a MailProcessor that depends on the subscription, but doesn't own the creation of the Yugo.Client, being linked in the supervision tree to ensure whenever the client is restarted, the processor will be as well (which triggers a new subscription). In some of my use cases, this is actually a dynamic supervisor with the paired children being added on the fly. This general approach has addressed any silently lost messages for me so far.

Hope that helps.

[Flying-Toast]

@bkono That exit handling change looks like a good addition to me, would you want to send a PR for it?