st2 rule ValidationError after upgrade from st2 2.6.0 to 2.7.2 (Jinja not rendering properly?)

[stevemuskiewicz]

ISSUE TYPE

• Bug Report

STACKSTORM VERSION

st2 2.7.2, on Python 2.7

OS / ENVIRONMENT / INSTALL METHOD

RPM installation on CentOS 7.x

SUMMARY

I have an st2 rule definition that was previously working fine under st2 2.6.0. After upgrading to st2 2.7.2 (with no changes to the rule definition), I am now finding it is throwing a ValidationError against one of the action parameters in the rule definition:

Traceback (most recent call last):
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/st2reactor/rules/enforcer.py", line 94, in enforce
    execution_db = self._do_enforce()
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/st2reactor/rules/enforcer.py", line 143, in _do_enforce
    additional_contexts=additional_contexts)
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/st2reactor/rules/enforcer.py", line 199, in _invoke_action
    liveaction_db, execution_db = action_service.create_request(liveaction_db)
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/st2common/services/action.py", line 89, in create_request
    allow_default_none=True)
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/st2common/util/schema/__init__.py", line 294, in validate
    jsonschema.validate(instance=instance, schema=schema, cls=cls, *args, **kwargs)
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/jsonschema/validators.py", line 541, in validate
    cls(schema, *args, **kwargs).validate(instance)
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/jsonschema/validators.py", line 130,
   in validate
    raise error
ValidationError: u'{{trigger.body.pullrequest_id}}' is not of type u'integer'
Failed validating u'type' in schema['properties'][u'prid']:
    {u'description': u'Pull request ID',
     u'required': True,
     u'type': u'integer'}

however the actual trigger body payload for the rule from st2rulesengine.log seems to be the correct (integer) type:

'payload': {'body': {u'request_user': u'ReRunner', u'pullrequest_id': 2401, ...

Seems like st2 is not rendering the Jinja before validating it.

As suggested in Slack, I also tried casting the parameter with | int in the rule definition but that doesn't appear to address the problem, still seems like the Jinja isn't rendered.

Here's my rule declaration:

---
    name: "reset_pr_bldstat"
    pack: "pxops"
    description: "Reset pull request build status"
    enabled: true
    trigger:
        type: "core.st2.webhook"
        description: "Reset PR build status incoming webhook"
        parameters:
          url: "pr/build/status/reset"
    criteria:
        trigger.body.webhook_event:
          type: "equals"
          pattern: "prbuild_reset_status"
    action:
         ref: "pxops.reset_build_status"
         parameters:
            repo: "{{trigger.body.repository}}"
            prid: "{{trigger.body.pullrequest_id}}"
            requestUser: "{{trigger.body.request_user}}"

This seems similar to this issue: https://github.com/StackStorm/st2/issues/4050

Some discussion of this on the Slack forum:

https://stackstorm-community.slack.com/archives/C066APT88/p1527787880000773

[stevemuskiewicz]

@Kami Any thoughts/updates on this one, I'm up to st2 2.8.1 and it still seems to be a problem, now I've got another rule that isn't validating which looks to be the same issue (validator is running against the Jinja syntax and not the actual data that Jinja substitutes:

ValidationError: u'{{trigger.body.build_metadata}}' is not of type u'object'

Failed validating u'type' in schema['properties'][u'build_data']:
    {u'required': True, u'type': u'object'}

[Kami]

@stevemuskiewicz I haven't had a chance to look into it - I will look into it early next week.

In the mean time it would help if you could provide as much details / context as possible so I can try to replicate it then (whole trigger instance object with payload, etc.).

[stevemuskiewicz]

@Kami thanks, I think I've got a bead on what's going wrong, might be a corner case or me just doing something wrong 😀

In my rule definition I had:

---
    name: "build_completed"
    pack: "pxops"
    description: "Build completed"
    enabled: true

    trigger:
        type: "core.st2.webhook"
        description: "Build completed incoming webhook"
        parameters:
          url: "build/completed"

    # build completed criteria
    criteria:
        trigger.body.webhook_event:
          type: "equals"
          pattern: "ci_build_completed"

    # action for build completed
    action:
         ref: "pxops.build_completed"
         parameters:
            # NOTE: need "or ''" conditional on optional parameters;
            # otherwise they seem to end up as literal "None"
            build_data: "{{trigger.body.build_metadata}}"
            metadata_url: "{{trigger.body.metadata_url or ''}}"
            exec_host: "automaton"

but in the case of the triggering system, the metadata_url parameter was supposed to be optional and some systems weren't sending it at all. At some point (earlier 2.x versions of st2), I had put in the "{{trigger.body.metadata_url or ''}}" syntax to deal with this as I was finding when the parameter wasn't passed I was getting a literal "none" string in that field in my action.

Anyway, I found that if I commented out metadata_url in the rule and the corresponding action then the rule no longer had a validation error and the action ran successfully.

So not sure if my "{{trigger.body.metadata_url or ''}}" syntax is incorrect or if I can now just omit the or "" part and have it get handled properly (not putting "none" in my action data when the value isn't found). I still need to double back and find a system that provides this field in the rule trigger body and see if it works the other way.

At least I have a workaround for now, if there are any more specifics I can provide (or a more "proper" way to handle this parameter in my rule declaration 😀 ) let me know.

[stevemuskiewicz]

@Kami @LindsayHill I've been bitten by this one again, this time when I tried to use a keystore value in my rule definition. (This is in st2 2.8.1). So for this rule definition:

---
    name: "build_completed"
    pack: "pxops"
    description: "Build completed"
    enabled: true

    trigger:
        type: "core.st2.webhook"
        description: "Build completed incoming webhook"
        parameters:
          url: "build/completed"

    # build completed criteria
    criteria:
        trigger.body.webhook_event:
          type: "equals"
          pattern: "ci_build_completed"

    # action for build completed
    action:
         ref: "pxops.build_completed"
         parameters:
            build_data: "{{trigger.body.build_metadata}}"
            exec_host: "{{ st2kv.system_devops_automation_host }}"

I got exceptions during rule enforcements:

Traceback (most recent call last):
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/st2reactor/rules/enforce
r.py", line 96, in enforce
    execution_db = self._do_enforce()
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/st2reactor/rules/enforce
r.py", line 147, in _do_enforce
    additional_contexts=additional_contexts)
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/st2reactor/rules/enforce
r.py", line 203, in _invoke_action
    liveaction_db, execution_db = action_service.create_request(liveaction_db)
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/st2common/services/actio
n.py", line 92, in create_request
    allow_default_none=True)
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/st2common/util/schema/__init__.py", line 294, in validate
    jsonschema.validate(instance=instance, schema=schema, cls=cls, *args, **kwargs)
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/jsonschema/validators.py", line 541, in validate
    cls(schema, *args, **kwargs).validate(instance)
  File "/opt/stackstorm/st2/lib/python2.7/site-packages/jsonschema/validators.py", line 130, in validate
    raise error
ValidationError: u'{{trigger.body.build_metadata}}' is not of type u'object'

Failed validating u'type' in schema['properties'][u'build_data']:
    {u'required': True, u'type': u'object'}

On instance[u'build_data']:
    u'{{trigger.body.build_metadata}}' (_rule_db={'description': u'Build completed', 'tags': [], 'ref': u'pxops.build_completed', 'enabled': True, 'name': u'build_completed', 'trigger': u'core.f7d59e5d-ac56-497a-9d59-d7def2803c5d', 'context': {}, 'criteria': {u'trigger.body.webhook_event': {u'pattern': u'ci_build_completed', u'type': u'equals'}}, 'action': 'ActionExecutionSpecDB@140162642277840(ref="pxops.build_completed", parameters="{u\'build_data\': u\'{{trigger.body.build_metadata}}\', u\'exec_host\': u\'{{ st2kv.system_devops_automation_host }}\'}")', '
...

So it doesn't really seem like a corner case at this point, looks like any Jinja used in the action section of a rule definition is not being replaced with the rendered value before the validation occurs leading to exceptions.

LMK if you need additional info to try to reproduce this. thanks!

[stale[bot]]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically marking is as stale. If this issue is not relevant or applicable anymore (problem has been fixed in a new version or similar), please close the issue or let us know so we can close it. On the contrary, if the issue is still relevant, there is nothing you need to do, but if you have any additional details or context which would help us when working on this issue, please include it as a comment to this issue.

[stevemuskiewicz]

Still an issue in st2 2.9.1 for me

[stale[bot]]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically marking is as stale. If this issue is not relevant or applicable anymore (problem has been fixed in a new version or similar), please close the issue or let us know so we can close it. On the contrary, if the issue is still relevant, there is nothing you need to do, but if you have any additional details or context which would help us when working on this issue, please include it as a comment to this issue.

[stevemuskiewicz]

still an issue AFAIK