simln-lib: refactor ForwardingError to nested results #265
Conversation
| ) | ||
| } | ||
| } | ||
| type ForwardResult = Result<Result<(), ForwardingError>, CriticalError>; |
There was a problem hiding this comment.
Will the plan here to be to add a variant for interceptors in both CriticalError and ForwardingError which external implementations would use?
An alternative could be to just make this a BoxError instead of CriticalError so that callers don't have to wrap their errors. There's no getting round adding a variant for ForwardingError so seems reasonable to just do this consistently.
Mostly musing out loud, think we could go either way here.
There was a problem hiding this comment.
Will the plan here to be to add a variant for interceptors in both
CriticalErrorandForwardingErrorwhich external implementations would use?
yeah. If they encountered some regular error, provide it in something like ForwardingError::InterceptError(error) and if they encountered an error that warranted a simulation shutdown CriticalError::InterceptError(critical_error_msg)
There's no getting round adding a variant for
ForwardingErrorso seems reasonable to just do this consistently.
sorry, not quite sure I understood this part. Could you expand here a bit more 😅
There was a problem hiding this comment.
sorry, not quite sure I understood this part. Could you expand here a bit more 😅
Just meaning that we're definitely going to have to add ForwardingError::InterceptorError(...) so that interceptor errors can provide "inner" errors - basically what you said above!
Previously we were mixing regular fowarding errors like insufficient balance and critical errors that warranted a shutdown in the same ForwardingError type. Use nested results when propagating a payment to differentiate between them.
doing as a prefactor for #261
Previously we were checking for critical errors with
is_criticalon theForwardingErrorto trigger a simulation shutdown. Added aCriticalErrortype that includes the errors we considered critical and now returning them throughout the payment propagation in nested results to better differentiate between the 2 types of errors.