MERGE3 comes with a good number of log traces. Combined with logs from TCP, TP, Merger and other protocols, it provides a good understanding of what is happening in the application.
Yet, when it comes to the actual process of merge run by ViewConsistencyChecker#_run, we lack details about what happens before performing the merge. Particularly, we can track when VIEW_REQ messages are sent but we don't know what happen in the checker when responses are processed:

• which views were received?
• when are they received?
• what is the final result on which the MERGE3 logic is executed
• is the merge cancelled or aborted?

In my forked branch, I added 5 traces that helped me understand what was going on in my cluster.
Tell me if it is the right way to suggest improvements.

Regards