Suggestion re error rail handling

[edman]

Here's a nuisance I had with error rails:

DB::queryOneWithExactFields ...
|> Result::fromOption ...
|> Result::andThen ...

Assuming the DB call works, you'll get errors when you run this. First because fromOption expects an option and the DB call returns the unwrapped dict (it's on the error rail).

Then if you take the DB call out the error rail you get a new error because andThen expects a result.

---

One possible solution: when piping a function F that's currently on the error rail into a function that takes the wrapped error rail value, auto take F out of the error rail.

[pbiggar]

I like this solution. Preferably as well providing feedback to indicate that we did it.

Other users have suggested a setting to disable the error rail, it feels like this could address some of the frustrations that led to that ask.

[pbiggar]

We've removed the errorrail in Darklang-next, so closing this. I think it will be handled better as a result