Rewriting Return Code

Normally, when a module fails, the interpreter stops processing the current section and returns. In some cases, allowing an "early success", which means the server is instructed to stop processing the list on a success, may be preferable. This instruction is accomplished by adding a subsection after the module name. For example, rather than:

accounting {
    detail
    ...
}

the configuration would read as follows:

accounting {
    detail {
        ok = return
    }
    ...
}

In this example, the default action and the priority in the action table are replaced with the specified action and/or priority. The above configuration would cause the interpreter to stop processing the accounting section if the detail module returned ok.

On the other hand, if the goal is to have a "soft failure", then the interpreter should continue processing the accounting section even if the detail module returned fail. In that situation, the following configuration should be used:

accounting {
    detail {
        fail = 1
    }
    ...
}

The fail = 1 text tells the interpreter to remember the fail code with priority 1 in place of the default action for fail, which is return. This configuration allows the accounting section to return ok if another module succeeds and to return fail only if all of the other modules return fail.