While enabling tracing is VM-level operation, the trace messages themselves are standard Erlang messages send from traced process to process that is doing tracing (enabled tracing by call to erlang:trace/3
). So all inconsistencies are that you might experience are caused by asynchronous nature of message passing itself.
If A and C are tracing messages send by B they will see them in same order.
The other case could be easier explained with little different example: A is tracing messages send by B and C, while B and C are sending messages to D. In theory it is possible that A those messages in different order than D, but this would have to be a very extreme edge case.
But still that should not be a problem for understanding your system, if you would like to know the order of messages received by D, you trace messages received by D. And just to be sure, you should also trace functions called in receive
clause (if you have any), because receiving message might be different thing that processing received message.
In general, just like it is a good idea to wrap your message sending in function calls, it is a good idea to trace functions, since they are thing that are being executed. Only exception would be debugging receive
clause where some guards or pattern matching could cause process to ignore one of the messages. And it is a good practice to have a function call (and preferably nothing else) in each receive
clause, since this is something you can actually trace.