What happens when the [ERLANG_QUESTION29] process receives a message that is not expected?

A third-party library has recently been upgraded in the project, resulting in the application gen_server in a process:

Handle_info ({add,x},sum),      {noreply,sum+x};

The result is a job that is so simple that it does not work, a check, found that the third-party library process B sent messages from

{add,x}------->{plus,x}

A large amount of {plus,x} information is stored in a process, which makes the memory consumption of this process also become abnormally large.

After simple repair, inadvertently thinking: in the end how to deal with those we do not expect the news? （ This kind of mistake is the other person should not send this message to me, it is not my own fault）

1. You can record these messages:
    1a.) as Info    1b.) as warning    1c.) AS Error
2. Count the messages, and then what do you do with the numbers? 3. Ignore them directly, do not trace?
4. Let the server directly crash out?

Google gets a very interesting vote in maillist: How do you deal with messages unrelated to your process? Http://erlang.org/pipermail/erlang-questions/2014-August/080420.html's views are mostly focused on the nature of the process: 1. According to the process Life cycle: If it is the process of short life cycle (short-lived), you can use different log levels to record these messages, which will help to find the real problem, do not position the problem to the receiver, pay more attention to who sent him, why it was sent to a wrong process, What results will this result? 2. According to the process Quantity: If the number of such processes is large, it is ignored directly, do not do trace, to avoid pressure on the log io. 3. According to the process Importance: If it is possible to process calls/casts/monitors/exits messages, what messages should we record to make them abnormal? And most of the other processes, we should ignore it directly, do not do trace. 4. "Let it Crash"Philosophy: Whatever it is, let it be crash. The above "Let it crash" inevitably a bit too far-fetched, this fault is not from their own, why to let others the wrong influence to their own, other points of view is very reasonable, but Fred (learn some Erlang author) summarized very exciting, share the following:

I tend to go the log route. There isn ' t a super good reason, but the wayi think about it is a bit of probability. When does I send messages to the wrong process? A few ideas are:-Manual debugging-typoes-a refactoring gone bad-initial design got messed up-erroneous Third-party Co De that doesn ' t come from my precise development right away.  Then the question was what was the consequences I want.-Manual debugging:do Nothing, I ' m poking around-typoes:i had to  Know about these asap-refactoring gone bad:i had to know about these asap-initial design got messed up:something had To is loud and Bad-third party code:i want the third party to suffer. For these reasons, I tend-to-take the following approach:-in HANDLE_CALL/3, I-Log the event with a string a bit like "mo D=mymod at=handle_call warning=unexpected_call msg=~p "and then return ' {noreply, State} ' to force the caller to crash AF ter a timeout. It ' s their fault, not mine.-in other callbacks, just log similar messages, Replacing At=handle_call with At=handle_cast|info and Warning=unexpected_cast|info. I can, from time-to-time, look at logs for ' warning=unexpected_* ' inlogs and see if something is going weird. If It's something happening rarely, I ' m gonna has traces, but withoutthe weird failures (unless it's a call). If it ' s something frequent,bugs would either show themselves differently, the log volume would bevery high, and so on. It tends to give me what I need given the circumstances. It's not alwaysas loud as I ' d expect (except for calls, which is ideal), but it tendsto give me enough visibility for the Occasional stray message, withoutcompromising service levels.

Specific unknown message can be divided into:--manual debugging--handwriting Error--Refactoring code error--The original design confusion--the third party code library to bring the wrong specific method can: In the HANDLE_CALL/3 will be recorded and then returned:

Handlle_call (msg,_from,state),   log: ("mod=~p at=handle_call warning=unexpected_call msg=~p", [?  MODULE,MSG]),   {noreply, state};

Force caller crash, it's their fault, don't blame me. Then check the log for ' warning=unexpected_* ' information repeatedly.

Running Dialyzer on my codebase:

What happens when the [ERLANG_QUESTION29] process receives a message that is not expected?