Event here, event there, events flying everywhere. Post about checking that every Akka event will finally find its home
Akka and reactive, event-based applications are a new approach to creating software. We are using Akka pretty intensively in our current Scala-based project. Events fit our use cases especially well as we are communicating with external APIs which might be slow. This could damage user experience when handled using traditional synchronous approach. But luckily, our requests can be performed asynchronously so passing them to Actor seemed a good idea.
When things get ouf of control
But while being cool and very useful, events can still hurt project when handled by inexperienced hands. Asynchronous nature makes application flow hard to understand at first glance. And each time you add a new actor or event type to your system, probability that you will forget to handle something properly increases.
Let’s look at the example class, this is an actor handling events associated with Image tags and comments:
and when you add next event, let’s say MostLikedFriendImage you can easily forget to add handler case section in actor, especially if there is more than one actor listening for this type of event.
DRY violating solution
There is one simple solution that will allow to detect forgotten handlers. We can add case _ to each actor:
And while it looks pretty ok for one or two actors, adding same code fragment to multiple actors is troublesome and violates DRY principle. But, what is most dangerous, someone in your team could forget to add it (as someone said “Every manual task that can be forgotten, will be forgotten”). So maybe we should pursue better solution?
React on ANY unhandled event
Luckily, we are not stuck with our error-prone approach. When actor can not handle event that was passed to him UnhandledMessageis raised and published to ActorSystem’s EventStream.
So to handle every forgotten event we could create listener and subscribe it to EventStream:
And subscribing code fragment:
and that’s it. Now every time there is an event that wasn’t handled by actor, we will know about it, especially when application is deployed in a non-production environment :)