Make managing actor selector less error prone

[ryanmiville]

I find myself always needing to include my Selector in my actor’s state for any non-trivial actor, or even for trivial actors that are under a supervisor. This feels like I’m carrying around an implementation detail.

Aside from it being cumbersome, I am frequently making mistakes that the compiler can’t catch. It is very easy to accidentally orphan a Subject for your actor if you forget to pass your selector forward on a branch.

Possible Solution

Add a way to merge new selectors into the actor’s current selector. Users won’t need to worry about managing their selectors manually.

Design 1: Add a new Next variant

pub type Next(message, state) {   
  Continue(state: state, selector: Option(Selector(message)))
  AddSelector(state: state: selector: Selector(message))
  Stop(ExitReason) 
}     

then merge it with the existing one in actor.loop. Avoids any breaking changes, but feels janky.

Design 2: Make a breaking change to Next

This is effectively the same idea, but I prefer this because it models things better.

pub opaque type NextSelector(message) {   
  SameSelector   
  AddSelector(Selector(message))   
  ReplaceSelector(Selector(message)) 
}  

pub type Next(message, state) {   
  Continue(state: state, selector: NextSelector(message))
  Stop(ExitReason) 
}    

Example usage

No need to store selector in state, and hard to accidentally orphan subjects.

fn my_actor_loop(message: Message, state: State) {
  case message {
    CallAnotherActor -> {
      let selector = call_another_actor()
      actor.continue(state) |> actor.add_selector(selector)
    }

    OtherActorResponse(_) -> actor.continue(state)

    StartChild -> {
      let assert Ok(child) = actor.start(child_spec())
      let selector = monitor_child(child)
      actor.continue(state) |> actor.add_selector(selector)
    }

    ChildDown(_) -> actor.continue(state)
  }
}

[lpil]

There are two ways that the programmer can misuse this part of the API: accidentally dropping selections still in use, and accidentally retaining selections.

If the programmer accidentally drops selections when a messages arrives for them the actor discards it and logs a warning, alerting the programmer to the mistake.

If the programmer accidentally retains selections the consequences are much harder for the programmer to detect. The selector grows in size each time, resulting in a memory leak and a performance leak, neither of which the programmer is likely to detect before it causes an incident in production, and then it will be very challenging to find.

Of the two options we favour the much easier discarding of selections failure mode, making it more likely to prevent the other.

An API with two options could be good. I'm interested in other people's thoughts here.

[ryanmiville]

I hadn't considered the case of the selector growing too large. I understand the design choice much better now. My proposal wouldn't help the programmer avoid that, but that may be OK. It just means the programmer will still have to manage their selector manually if that is a concern for their actor.

I think this could occur in situations where you add a selector and expect only a single message on that subject, that may happen a lot over the lifetime of the process. Things like process monitoring, and sending and expecting a response to another process.

Do you think there's value in exploring an API for a receive-once selector?

[lpil]

What's a receive once selector and what are some situations in which it would be used?

[ryanmiville]

I thought about it more, and I’m not sure it’s a good idea, and it’s a bit of a tangent from this issue’s core idea anyway.

I was envisioning a specialized kind of entry in the selector’s Handlers map that gets removed from the map after it receives a message.

Use cases that come to mind are process down monitoring, and performing a request/response with another process. Things where that Ref will only receive a message one time, and no longer need to be held in the selector.

[lpil]

That's an interesting idea. Monitors and down messages can only be received once, after all.