Create RuleEnforcementDB object for trigger instances / rules which resulted in an exception in the rule filtering phase #4134
Conversation
to match rule inside the rules filtering phase due to an exception. This way user has more visibility into matches which failed because of an exception (failed to render Jinja expression, etc). Without this change, only way to find those rules is by checking rules engine service log.
Also fix existing test cases so they don't rely on each other and can be run indepdently of each other.
Kami
force-pushed
the
rule_enforcement_improvements
branch
from
70f7742 to
9c11d01
Compare
views controller.
quoted when projection is used on a query (aka only want to retrieve a subset of fields or similar).
rule enforcement objects enriched with additional data useful to the WebUI and various clients (right now that's execution parameters and action ref).
corresponding trigger instance object.
|
I discussed this with @enykeev some more and we agreed it would be good to add some new rule enforcement view API endpoints:
Example response format can be viewed here - https://gist.github.com/Kami/07a061b5261b0064c23962bbe1f50dff. Similar as other view API endpoints, this API endpoint returns aggregated data from multiple objects which reduces load and unnecessary HTTP requests on the client side. In this case, the endpoint returns RuleEnforcement object with the corresponding TriggerInstance and Execution object (in case trigger instance resulted in an action execution). TriggerInstance object is small so the whole object is included, but Execution can be quite large so right now only the fields which are needed by the UI are included (action reference and action input parameters). Before this change, WebUI would need to make three HTTP requests to assemble "single rule expanded pane view" page (get rule enforcement, get trigger instance, get execution), but now it only needs to make one. In the end it reduces load on the client and provides a better and faster user-experience. Keep in mind that this API endpoint can be used by other clients which want to provide more detailed views, not just WebUI. |
When this argument is True, we use object ids (primary keys) from fixture files when saving objects in the database. This allows us to re-create reproducible tests in cases when tests rely on fixed ids without needing to mock a lot of things (mocking is error prone and not robust in a lot of scenarios).
in the execution object of rules view API endpoint result.
|
Here is how the output looks right now with some additional fields (action.parameters, runner.name, runner.runner_parameters, status) added - https://gist.github.com/Kami/501ba43d011e0f54b02f60e322734df9 |
are not ordered correctly, router will match a wrong path.
This reverts commit 2ff0788.
For backward compatibility reasons, default it to "succeeded".
|
As per discussion with @enykeev, I also added new This field can contain the following values:
For backward compatibility reasons, default value for this field is |
This pull request updates the code to also create
RuleEnforcementDBobject for trigger instances which resulted in an exception and failed to match the rule in the rules filtering (matching) phase.This could for example happen if rule contains an invalid Jinja expression and similar.
This change increases the user visibility. Previously it was only possible to find about those trigger instances and rules by checking the rules engine log file.
Some people could argue that this doesn't really belong into
RuleEnforcementDBobject per say and we should have a separate object for that (e.g.RuleFilteringFailureDBor similar), but I think this would increase the complexity for no good reason (and StackStorm is already quite complex and we already have quite a lot of models).Keep in mind that we only create
RuleEnforcementDBobject for rules which result in an exception - we don't createRuleEnforcementDBobjects for trigger instances which didn't match any rules due to simple criteria match failure (that would be an inverse forRuleEnforcementDBobject and I think I have a better idea for handling that below).This change was originally requested by @dzimine / @enykeev. After I looked into the code, I agreed is a good idea since it increases the user visibility into the rules matching.
To increase visibility further, I would suggest to have another API endpoint or similar which returns a list of
TriggerInstanceDBobjects that didn't match any rule.This could be implement quite easily by checking for all
TriggerInstanceDBobjects in the system which don't have correspondingRuleEnforcementDBobjects. Keep in mind that this could be quite expensive (there could be manyTriggerInstanceDBobjects in the database) so we should keep performance in mind.TODO