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.