[sr-dev] Kill t_relay() return codes. Long life to failure_route.

[Iñaki Baz Castillo]

Hi, t_relay() negative return codes is something ugly, more when there
is parallel or serial forking. For example:

- Parallel forking to two different locations.
- The first destination gets a -4: bad destination (unresolvable address).
- The second destination gest a -5 - destination filtered (black listed).
- But t_relay() would reply just one of both codes.

Also when mixing UDP and TCP branches t_relay() return codes get more
complex to evaluate. For the same kind of error in UDP t_relay()
returns true and we get into failure_route, and in TCP t_relay()
returns a nevative value and failure_route is not executed. This is
difficult to manage, too much exotic cases. Mixing it with parallel
forking we get something really terrible.


So I wonder, shouldn't be better if we forgot the t_relay() codes and
instead handle the error of the winning branch (even if it failed or
it was no branch) in failure_route?
This could mean new functions to be executed in failure_route, something like:

- t_no_destination_available:
Returns true if the failure route is executed because no branches were
added or request was already cancelled. It would generate a local 500
error by default.

- t_branch_bad destination:
Returns true if the failure route is executed for a branch whose
destination was an uresolvable address. Generates a local 500 error
(or perhaps other).

- t_branch_destination_filtered:
Returns true if the failure route is executed for a branch whose
destination was black listed. Generates a local 500.

- t_branch_tcp_error:
Returns true if the failure route is executed for a TCP branch for
which the connection was not possible. Generates a local 500.

- t_failed:
Returns true if no request could be sent for this transaction (any of
the above returns true).  Generates a local 500.

...and so on.


Then any code we actually run into "if ! t_relay() {  ... }" could be
executed in failure_route and we get an easier and solid way to handle
errors (instead of mixing t_relay negative values, local generated
negative responses in failure_route and so).

Also this would mean that t_relay() terminates the request process, it
acts as "exit();". Then we can inspect failure_route to get the result
in case it's negative.


Opinions? I strongly think it would be really better than the current behavior.



-- 
Iñaki Baz Castillo
<ibc at aliax.net>