What is the difference between the PidLifecycleEvent enum and the GroupChangeMessage enum ?

[phil-skillwon]

I see that the comments for these two enums are very similar:
/// Represents a change in group or scope membership
#[derive(Clone)]
pub enum GroupChangeMessage {
/// Some actors joined a group
Join(GroupName, Vec),
/// Some actors left a group
Leave(GroupName, Vec),
}

/// Represents a change in group or scope membership
#[derive(Clone)]
pub enum PidLifecycleEvent {
/// Some actors joined a group
Spawn(ActorCell),
/// Some actors left a group
Terminate(ActorCell),
}

Do PidLifecycleEvent have any relation to the lifecycle of remote actors?

[slawlor]

Yeah that's a bad copy-paste comment on my part. I'll update it.

A PidLifecycleEvent triggers when any pid has an event (spawn/terminate). It's presently only enabled with the cluster feature as it's needed for distributed actor notifications.

Group changes are updates from pg groups (process groups). They are part of the base library, and are groups of actors grouped together into named groups. Erlang's documentation (https://www.erlang.org/doc/man/pg.html) gives a good overview and motivation.

[phil-skillwon]

What is PidLifecycleEvent used for and can you provide some simple examples? In my cluster testing project, my custom actor did not receive this supervision event.

[slawlor]

There's a unit test which demonstrates it, called test_pid_lifecycle_monitoring. You need to "enroll" to receiving the callbacks for pid lifecycle events (since there could be hundreds/thousands depending on the architecture of your system). It's a non-trivial event stream to subscribe to.

Specifically you can call what's called in ractor_cluster/src/node_session/mod.rs:665

// setup PID monitoring
ractor::registry::pid_registry::monitor(myself.get_cell());

which will set the ActorRef<_> "myself" as a callback target for PID lifecycle events.

[maulanadenden]

// setup PID monitoring
ractor::registry::pid_registry::monitor(myself.get_cell());