Hi, imagine this simple case:
-------------------------- route { t_on_branch("1"); t_on_failure("2");
xlog("We are in 'route'"); t_relay("1.1.1.1"); }
branch_route[1] { xlog("We are in 'branch_route[1]'"); # do something.... }
failure_route[2] { xlog("We are in 'failure_route[2]'"); append_branch(); t_relay("2.2.2.2"); } ---------------------------
In case an error occurs when forwarding the request to 1.1.1.1 this would be the screen log output:
We are in 'route' We are in 'branch_route[1]' We are in 'failure_route[2]' We are in 'branch_route[1]'
This is: branch_route[1] will also be runned **again** after the failure route since it was loaded in the first forward attemp.
I really don't know if this is intuitive or not. The only way to "dissable" branch_route[1] in the failure route is by adding:
------------------- failure_route[2] { t_on_branch("2"); # <--- Dissable t_on_branch("1")
xlog("We are in 'failure_route[2]'"); append_branch(); t_relay("2.2.2.2"); }
branch_route[2] { xlog("We are in 'branch_route[2]'"); # Nothing to do here. # This route is neccesary to dissable t_on_branch("1") } ------------------
This would show:
We are in 'route' We are in 'branch_route[1]' We are in 'failure_route[2]' We are in 'branch_route[2]'
What about if "t_on_branch" wouldn't remain loaded after a failure route or serial forking? wouldn't be more intuitive to re-enable it explicitely when required?