Closed dmbaio closed 4 years ago
Hi @BobSilent, I saw in another thread that you have been rather busy lately so apologies if you still are. Do you think that this issue is a bug on the aggregator side or ADO side?
For service hooks that are triggered by work item updates, when rules execute and save changes back to DevOps, those changes also then trigger the service hook again.
Correct, as an update is an update, so there is no difference.
Since the function app doesn't save any changes if the values already equal what the rule has, the rule runs a second time but it does not make any changes the second time and so it does not get triggered a third time. The exception is if the rule is set to increment the value of a field, then every update triggers the rule again and traps it in a loop. Is this a bug or something that is unavoidable on the Aggregator side and has to be compensated for in the rule codes to prevent loops?
The rule exit criteria needs to be defined and it is one of the most important steps when writing a rule, see also my answer here.
You can also define an exit criteria on the changed value(s) with selfChanges
.
So for example:
Thanks!
Obligatory "not sure if this is a bug". For service hooks that are triggered by work item updates, when rules execute and save changes back to DevOps, those changes also then trigger the service hook again. Since the function app doesn't save any changes if the values already equal what the rule has, the rule runs a second time but it does not make any changes the second time and so it does not get triggered a third time. The exception is if the rule is set to increment the value of a field, then every update triggers the rule again and traps it in a loop. Is this a bug or something that is unavoidable on the Aggregator side and has to be compensated for in the rule codes to prevent loops?