don't apply Throwable into replica, only valid entries

[mariusz-jachimowicz-83]

Fix #10 - No defmethod extensions/apply-log-entry when entry is Throwable

[lbradstreet]

This is good, but I think we need an error callback fn, or similar. Otherwise the subscriber will be dropped and upstream will never know it. If we allow an error callback fn to be passed, at least this can be handled

[mariusz-jachimowicz-83]

I don't like callbacks. It leads to more complicated code, harder to reason about and test. I can add this callback if you want. I did it this way because I am working on fail fast strategy in onyx dashboard so it might be temporarly solution generally.

[lbradstreet]

To be honest, I'm not a fan of callbacks myself. I generally try to avoid them, and Onyx almost never uses them. However this code uses them as the main form of communication.

Leaving aside beliefs regarding callbacks, if we ignore the exception here, and do not pass it back up to the code that has created a replica view on the cluster, the owner will never know that something has gone wrong.

I am open to thoughts on how the API should work. If we are going to make a breaking change to allow for an error handling callback, then I'm happy to make a breaking change for another approach, assuming it makes sense.

Btw, fail fast code is fine, but I don't see how the code that is calling this will know that the code has failed (not your fault, we didn't handle it originally, but we shouldn't just ignore it, which is what we would be doing in the when-not, if we ignore any exception values)

[mariusz-jachimowicz-83]

Generally I have only noticed ZK exceptions sent by channel for now. But there might be sent other kind of exceptions.
ZK connection lost/reconnect could be recognized by connection listener and can be handled properly, I think. This listener could restart subscription. But there are also exceptions when ZK node not exists so I am also thinking how to handle this problem in the platform. I am thinking about pure functions that can fail fast and sent, send some info that error occur to the central place that could do futher actions. I am experimenting now a little bit.

My intetion of this PR was only to temporarly fix problem without making breaking change. Didn't want to make this method fail fast, I am not ready for it yet.
You have a lot more experience then me so feel free to write any instructions. I will rewrite PR respectively.

[lbradstreet]

No worries, it's mostly due to our bad design in the first place. I'll get back to you with how I think the problem should be solved. Thanks!