Rule criteria regex matching against list objects

[dylan-bitovi]

ST2: 3.5

My use case is not so different than this old ticket: #2656

I'm processing Jira ticket webhook data, the components field on a ticket returns a list when called with:
trigger.body.issue.fields.components.name
e.g [ Component, Three Word Component ]

After testing with the regex function and st2-rule-tester there doesn't seem to be a way of checking a list object for multiple items as part of a criteria.

I can't use contains against the object in the criteria twice as then I cannot register the pack as there is a duplicate key in the criteria field which is a dictionary type thus causing an error.
e.g

  trigger.body.issue.fields.components.name:
    type: contains
    pattern: "Component"
  trigger.body.issue.fields.components.name:
    type: contains
    pattern: "Three Word Component"

Will fail at register_pack during the install process.

Using regex seems to partially work as I can register my regex function, but it seems to drop the value and pattern when used against a list (tested with st2-rule-tester):

2021-09-17 13:37:47,895 INFO [-] Validating rule my_pack.regex_criteria_test for 081fdd29-f1d3-4f10-ace8-0b22c9359059.
2021-09-17 13:37:47,896 DEBUG [-] Trigger payload:
2021-09-17 13:37:47,901 DEBUG [-] Rendered criteria pattern: ^(?=.*Component)(?=.*Three Word Component).*
2021-09-17 13:37:47,910 ERROR [-] There might be a problem with the criteria in rule my_pack.regex_criteria_test
Traceback (most recent call last):
  File "/opt/stackstorm/st2/lib/python3.6/site-packages/st2reactor/rules/filter.py", line 161, in _check_criterion
    result = op_func(value=payload_value, criteria_pattern=criteria_pattern)
  File "/opt/stackstorm/st2/lib/python3.6/site-packages/st2common/operators.py", line 265, in regex
    return regex.search(value) is not None
TypeError: expected string or bytes-like object
2021-09-17 13:37:47,914 INFO [-] Validation for rule my_pack.regex_criteria_test failed on criteria -
  key: trigger.body.issue.fields.components.name
  pattern: None
  type: regex
  payload: None
2021-09-17 13:37:47,914 DEBUG [-] Rule 6143ae921f112167fbeb6676 not applicable for 081fdd29-f1d3-4f10-ace8-0b22c9359059.
2021-09-17 13:37:47,914 DEBUG [-] [1st_pass] 0 rule(s) found to enforce for 081fdd29-f1d3-4f10-ace8-0b22c9359059.
2021-09-17 13:37:47,914 DEBUG [-] [2nd_pass] 0 rule(s) found to enforce for 081fdd29-f1d3-4f10-ace8-0b22c9359059.
2021-09-17 13:37:47,914 INFO [-] 0 rule(s) found to enforce for 081fdd29-f1d3-4f10-ace8-0b22c9359059.
2021-09-17 13:37:47,914 INFO [-] === RULE DOES NOT MATCH ===

e.g:

2021-09-17 13:37:47,901 DEBUG [-] Rendered criteria pattern: ^(?=.*Component)(?=.*Three Word Component).*

When I change the above variable to a part of the webhook data that's string or number it behaves normally with no error or otherwise operates as expected.

I tried playing around with publishing variable data higher up in the rule to see if I could get ahead of the criteria in any way, but there didn't seem to be anything that worked.

I also attempted to use YAQL/Jinja functions to see if I could apply them directly on the value such as str() or join(" ") but they would cause errors at trigger execution time.

Writing separate rule files for each wouldn't work as I need the logical AND functionality of checking both at once. Validation can be done as part of the workflow, but it would be more ideal if it we could filter it without calling any action.

My questions are so:

• Is there a way to force a criteria value to be string literal (or other type)?
• Is it out of the question to ask that the regex match functionality allow for list and set types by adding a list to string function in the regex operator if one is detected?
• Is there some other way that this could be solved? (e.g Writing custom webhook sensor receiver? Something easier I am missing?)

Writing a custom sensor to get around an object type seems a bit extreme, but I'm curious if there's something I'm missing.

Not sure if I should submit this as a bug or a feature request :)