execution of the rules should be independant so that failure of one rule shouldn't stop execution of other rules

[yan95g]

TFS aggregator Server Plugin 2.3 on TFS On-Premise 2017u2

there some rules which may be compiled ok and process some cases right according to business logic, but it may have some runtime cases which throws exception (like null pointer) and this exception stop processing other rules,

"run time null pointer example" - when you trying to read not defined field (like Completed Time without any value).

As soon as somebody start debugging - it isn't clear which rule is failed as many of those didn't execute up to the policy.

Expected behavior would be to fail certain rule and continue process other rules

[jessehouwing]

To be honest I feel there are two reasons why we should not implement this:

• we have no way of knowing whether the rule left a number of work items in a half processed state, which may cause all kinds of issues with future rules.
• other rules may expect that previous rules have already precalculated or changed certain fields in certain ways.
• there is a big perf overhead if we save every work item after every rule, not to mention the added number of round trips.

So unless we implement some kind of before rule/after rule snapshotting, which is a lot of work and may be especially hard if state transitions are involved, I do not see a valid reason to implement this.

If your rule is 'safe', wrap it in a try/catch. If you can provide roll-back in the catch, all the better. I don't expect we can offer a great experience which won't cause all kinds of other unexpected mayhem.

It's also why we have extensive logging and offer additional checks in the debug enabled version of the aggregator. You can also debug rule by rule on the failed work item from the commandline.

One thing which may be nice to add though, is a more verbose output on the console app, logging before/after values of fields and which work items were updated and which caused errors when. The latter is already in there, but the console could be better.

If you're tracking tfs of the vsts service hook using appinsights, new relic, app dynamic or other monitoring tools, our traces should already show up.