Brian Candler wrote:
I understand that, so let me write it more clearly:
1. the 'reject' state is being set at the beginning
No. It definitely doesn't do that.
2. the 'update' module returns 'updated' but this is discarded, hence the return code remains at 'reject'
"updated" is a lower priority than "reject". See doc/configurable_failover. It's obscure, but useful.
3. the 'reject' result is being *ignored* when the update{} block completes 4. the 'reject' result causes a return when the outer if{} block completes
Well, yes.
So: an update inside an 'if' causes a reject return; an update outside of an 'if' leaves the result as reject but doesn't return.
If that's the designed behaviour, it's pretty obscure.
Well, yes. As always, patches are welcome for suggested behavior. Alan DeKok.