Retrying failed side-effectful actions is the bread & butter for all programmers. Whether you use Python, Ruby, Java, or Scala, you’ll use the same retry strategies: usually some backoff and randomness.

In functional Scala, we use the powers of referential transparency (RT). If your API call is described as an IO value, you just create a new IO value that adds the retry logic of your choice. Easy, right?

Things get nasty very quickly when an API or a DB you call has more constraints. Imagine a retry strategy that starts with a 5ms delay and uses a Fibonacci backoff, but each individual delay is capped at 5s and you always do a final retry after the timeout passes. How would you make sure it’s working correctly? Is referential transparency helpful?

In this talk, I will discuss why it's hard to use the power of RT to test side-effect-heavy apps. The main problem is that our APIs and library APIs don't use the full power of RT: they focus too much on side effects and not the value representation of these side effects. This in turn makes testing such apps very difficult. I will present some alternative ideas for a better, more RT-friendly design for retries and many more side-effectful APIs.