ADO update logic needs improving

[mgreisen]

Information

• Onefuzz version: 5:15.0
• OS: n/a

When we detect a crash and need to update an ADO work item, we search to see if there is an existing item.

Current behavior that should be addressed:

• If we find 1 or more items, we update them all.
• When we update the work item, we update more than just the NumCount field (which is typically all we want to update).
• We will re-open the bug if it's closed and we don't take into account if the bug has been marked as a duplicate.

What we want:

1. If we find a matching work item(s), we should not re-open bugs if they are marked as a duplicate. Continue to work through the list to find a match that isn't marked as a duplicate and re-open that one. If all that has been found are duplicates, then re-open it, but add a comment explaining why we reopened it. [Draft] Chase Duplicate Of links when filing ADO bugs #2526
2. Update our ado.md docs to pick a different field in config.on_duplicate.ado_fields."System.IterationPath". IterationPath is not the best example of a field to update on duplicate bugs. Remove suggestion to reset IterationPath upon duplicate #2533
3. If we find multiple work items that aren't marked as duplicates, that seems like there is a problem. I'm not exactly sure what we want to do in this case. This is a case of our "uniqueness logic" failing us.

AB#41842262

[Porges]

3. If we find multiple work items that aren't marked as duplicates, that seems like there is a problem. I'm not exactly sure what we want to do in this case. This is a case of our "uniqueness logic" failing us.

This is also a little difficult because the uniqueness condition is specified in the notification config; the OneFuzz user can set this in any way they like.

[Porges]

2. Update our ado.md docs to pick a different field in config.on_duplicate.ado_fields."System.IterationPath". IterationPath is not the best example of a field to update on duplicate bugs.

(As an aside, this was being set in the ingestion service, and is no longer, so IterationPath won't be reset upon update. Once again this is a notification config setting and not specified in the core code.)

[tevoinea]

3. If we find multiple work items that aren't marked as duplicates, that seems like there is a problem. I'm not exactly sure what we want to do in this case. This is a case of our "uniqueness logic" failing us.

This is also a little difficult because the uniqueness condition is specified in the notification config; the OneFuzz user can set this in any way they like.

I've chosen to log telemetry for now and we can evaluate how frequently it's happening. It might make sense to notify the user that their uniqueness condition is failing.

[mgreisen]

3. If we find multiple work items that aren't marked as duplicates, that seems like there is a problem. I'm not exactly sure what we want to do in this case. This is a case of our "uniqueness logic" failing us.

This is also a little difficult because the uniqueness condition is specified in the notification config; the OneFuzz user can set this in any way they like.

I've chosen to log telemetry for now and we can evaluate how frequently it's happening. It might make sense to notify the user that their uniqueness condition is failing.

Per your comment here I've updated the task as "done" above.