Certain types of action trees may result in a return value of False, even if the tree completes correctly. This state usually occurs with MatchReplaceDef actions.

The image above shows a very simple version of the described scenario. If the action tree processes an e-mail message with [ELO] in the subject line, the tree returns a value of True, and if the text is not present, the tree returns a value of False.

However, all e-mail messages without [ELO] in the subject line will be recorded in the ELOxc logs as an error state, regardless of whether this result is a problem or not. This issue becomes even clearer when further processing states are added to the action tree.

The intention of the developer here seems clear: ELO-related messages should be moved to a specific folder, but all other messages can safely be ignored. However, non-ELO-related messages will cause the tree to return a value of False, which shows up as errors in the ELOxc logs. An excerpt:

Worker log:

The ELOxc job summary will also report an error for each item that causes this state.

The job summary also provides a summary of what caused each error, so it should be easy enough to determine that no actual error occurred. However, this is problematic for two reasons: first, an untrained observer may decide that the software is not running properly based on this overview. Second, and more importantly, the error report may mix these non-issues with actual problems in the software, making it more difficult to deal with actual errors when they arise.

To avoid this problem, make sure that every action tree returns True when it can possibly result in a desirable False result. Do this by adding a Result action to the tree:

Note that the Result action forces a True end to the tree when it would otherwise result in a False. After adding this action to the tree, the action in the comment will show up in the ELOxc logs but not report an error.

Worker log:

The ELOxc job summary will no longer report any errors.