Parallelism and multiple rules triggered on work item changed

[marnheus]

Hello.

I'd like to make sure I'm doing things the right way.

I have multiple events that can trigger different behavior on my user stories. Currently, I have implemented each behavior in different rules that are triggered by user story update. I guess if multiple behaviors/rules cause multiple saves at the same time, there will be issues right?
So should I implement all the behaviors in the same rule?

[giuliov]

Great question.
You must be careful to avoid cycles and loops: this version has no check for an infinite loop (it was possible with TfsAggregator because rules share the process memory).

Events

Let's start from the event that triggers a rule.
The workitem.created has no dependency on other rules but Azure DevOps may send it after a workitem.updated event!
The workitem.updated event has an additional selfChanges parameter and you should use to write a guard.

string magic = " - APPENDED";
if (selfChanges.Fields.ContainsKey("System.Title")) {
  // check it is not recursion
  var titleUpdate = selfChanges.Fields["System.Title"];
  if (!titleUpdate.NewValue.Contains(magic)) {
    self.Title = titleUpdate.NewValue + magic;
  }
}

The example (maybe a bit contrieved, but it's late here) checks that the change to the Title field was not made by the rule itself, to avoid infinite recursion.

Infinite loops

If you have more than one rule triggerd by workitem.updated, you must be careful to avoid loops between rules.

Here is what you must not do.

Rule A

self.Tags = self.Tags + " my-tag-A";

Rule B

string[] validTypes = new string[] { "Bug", "Epic", "Feature", "Product backlog item" };
if (validTypes.Contains(self.WorkItemType)) {
  self.Field["Microsoft.VSTS.Common.AcceptanceCriteria"] += "<p>My standard criteria</p>";
}

Rule A and B will trigger each other in an infinite loop.

Performance

Clearly independent rules are simpler to write but have a negative effect on performance. The more rules, the slower a work item will converge to a stable state.

Hope this help, and do not hesitate to ask additional questions.

[marnheus]

Yes this definitely helped and makes me think that I will refactor my rules to merge all in a single one where I check each field update. It will be a little less easy to navigate and to test but definitely better from a performance/stability point of view