Callbacks for join/leave
blt opened this issue · comments
It would be handy in some circumstances to have a registered callback for all voluntary join/leave events. That is, if a process identified by pid P joins group G, I would like some statically configured handle_join(Pid :: pid(), Group :: string()) -> ok to be called as handle_join(P, G), the idea here being you could 'bootstrap' newly joined processes to their group. Similarly a handle_leave/2 for leaves.
I say voluntary above, implying that processes which crash after joining a group will not result in such a call. Perhaps an additional callback to handle this case would be desirable?
I added support for this, however, the callback function arguments are reversed as: handle_join(Group :: any(), Pid :: pid()) -> any(). The other difference is that currently the join and leave callbacks will be called for anything that causes the pid to join or leave. Instead of having separate callbacks for separate reasons, I would rather add a Reason argument to differentiate between: join_local, join_remote, leave_local, leave_remote, and exit (I could probably add the reason for the exit too). The additional Reason argument could be optional.
I like the reason argument approach.
I added the reason argument, so that the callback can be either: handle_join(Group :: any(), Pid :: pid()) -> any() or handle_join(Group :: any(), Pid :: pid(), join_local | join_remote | {exit, any()}) -> any() as shown in the cpg:callback_join() type (with the same equivalent for leave). The join_local or join_remote difference shows where the join is originating from (so the pid may still be a local pid with a join_remote if the state is being updated from a remote node and relates to a local pid (not common, but a possible edge-case)). The other thing to keep in-mind is that the callback is called for each instance of the Pid in the Group, so if you join the same pid multiple times, the callback will be called the same number of times.
There was also a bug previously with the node monitoring, but that has been fixed (it was from a feature that was recently added in the v1.3.1.1 tag) and the code has been tagged. The new tag is v1.3.1.3.