We've defined the behavior of the Chef actor to distribute work across mixers but left the waiting part uncovered, so let's look at that now.

We left the Chef definition for the mixing behavior as follows: 

def mixing = Behaviors.unhandled[Command]

Actually, the Chef needs to know about the mixers that were created by its idle behavior. Though technically it is possible to do a children lookup, as described earlier, doing so will introduce an implicit assumption that, at the moment, we'll get the listing stating that all of the mixers are still processing jobs. This assumption might be wrong in a highly concurrent environment or in the case of failed mixers.

Therefore, we need to refactor the behavior constructor a bit:

def mixing(mixers: Set[ActorRef[Mixer.Mix]],
           collected: Int,
           manager: ActorRef[Manager.Command]): Behavior[Command]

Now, we have a builder that captures all of the parts of the Chef's state. Let's see how these parts are used in the definition of its behavior:

Behaviors.receivePartial {
  case (context, Collect(dough, mixer)) =>
    val mixersToGo = mixers - mixer
    val pastryBuf = collected + dough.weight
    context.stop(mixer)
    if (mixersToGo.isEmpty) {
      manager ! ReceivePastry(Dough(pastryBuf))
      idle
    } else {
      mixing(mixersToGo, pastryBuf, manager)
    }
}

We're already familiar with the constructor. In the behavior itself, we count every Dough message received from the mixer and recreate the behavior with the new state. In this case, if all of the mixers have delivered their parts, we return the result to the manager and go to the idle state.