Add an :allow_failure option to the organize method to swallow failure and continue execution

[laserlemon]

This probably shouldn't hijack context.fail! but instead should override the organizer's handling of an individual interactor's failure.

[hedgesky]

How would it play with rollbacking of a context? Currently it's launched automatically on failure.

I thought about passing a copy of a context to an organized interactor. It will complicate things significantly (need to contexts merging will arise) but allows us to isolate failures.

[laserlemon]

If :allow_failure is set to true for one of the organized interactors, I'm imagining that if that interactor fails, the organizer will recognize that failure and revert the context to a success before moving on. No rollbacks expected. I'd love to hear other suggestions if that doesn't feel right.

[mikebernardez]

Hey Steve, your gem is pretty central in our app -- thanks so much! 🥇

In our use-case, we don't foresee a need to call the rollbacks on previously run interactors.

We currently have some actions that call interactors in succession precisely because they are irreversible/doesn't make sense to reverse. Kind of like: organize: BuySomething, SubscribeEmail if SubscribeEmail failed, well, we don't really care about it vs BuySomething. Which is why we're handling them in succession vs putting it in an organizer(which with :allow_failure would now let us do I think).

[laserlemon]

@mikebernardez Great, thank you for the feedback!

[fluke]

Hey @laserlemon, thanks for your work on this gem.

Another use-case for this feature. If you have organize DoSomething, NotifyIfSomethingHappenedOrNot. In that case you might want the context to contain that it failed in the previous interactor. So maybe the context becomes a success but we have context.previous_state which might be fail or success.

[kevine-voicera]

I would love to be able to log and perform other actions on failure, but right now the fail hijacks and ends execution. Thoughts?