[Bug] Strange if-any condition interaction with if-not

[EternalllZM]

Cog

• [X] Defender
• [ ] Index
• [ ] Sbansync

Describe the bug For some reason, the if-any: condition will ignore if-not: when indented a certain way.

I have confirmed this with conditions:

• message-matches-any
• message-has-attachment

Therefore, the issue seems to be with using if-any instead of if-all.

To Reproduce Steps to reproduce the behavior:

  - if-any:
    - message-has-attachment: true
    - if-not:
      - user-has-any-role-in: [test role]
  - if-true:
    - delete-user-message:

From my testing, this rule format will ignore the if-not: condition and move on ahead with true. but ONLY if using if-any:

To fix, you must change the condition to if-all:, or change the rule to format like so:

  - if-any:
    - message-has-attachment: true
  - if-not:
    - user-has-any-role-in: [test role]
  - if-true:
    - delete-user-message:

The exact same rule, but setting the indention to the same as the other if conditions.

Expected behavior if-not should process regardless of whether it is indented or not in an if-any condition.

[Twentysix26]

As far as I can tell this is working as intended.

  - if-any: 
    - message-has-attachment: true #1
    - if-not:
      - user-has-any-role-in: [test role] #2
  - if-true: #3
    - delete-user-message:

Conditions inside a condition block (both simple conditions and nested condition blocks) are evaluated in sequence. if-any, which in boolean logic is a OR, bails at the first true condition (#1) it finds, because the condition block if-any is considered true if any of its inner conditions are true. This is due to Warden supporting short-circuit evaluation.
I gather that you were expecting for the condition #2 to have effect on #3, but that's just not how it works: individual condition results do not bubble up like that. The if-true will only be executed if the preceding[^1] condition or condition block, in this case the if-any, is true, otherwise it would lead to pretty unintuitive behaviour.

Hope this clear things up. If you still believe there's something not working as intended in the processing logic please provide a reproducible test case that uses the action compare, if possible.

[^1]: "preceding" indentation-wise, NOT processing-wise

[EternalllZM]

This makes sense. In that case, I will utilize if-all or format it properly to execute how I intended it to in this scenario. Thanks!