Impact
Build Insights observed 65 System.ArgumentException telemetry rows across 51 operations in a 24-hour production window. All selected exceptions correlated exactly with failed work-item telemetry. Affected work included build analysis and queue insights, and some work items exhausted attempt 3.
No raw telemetry, operation identifiers, customer data, or credentials are included here.
Evidence
BuildDataProvider.GetTargetBranch checks Azure DevOps build parameters for system.pullrequest.targetbranch, then checks TriggerInfo for pr.targetBranch. Some pull-request builds contain neither value. The method throws while mapping the Azure DevOps build into the domain model, before processors can apply their existing unavailable-target-branch handling.
The missing metadata remained consistent across retries. Retrying therefore repeated the same failure rather than recovering.
Likely root cause
A stable unsupported-input condition is represented as ArgumentException and handled by the generic work-item retry path. Confidence is high.
This hypothesis would be disproved if the original Azure DevOps payload contained either supported target-branch field, or if later attempts retrieved different metadata.
Suggested behavior
Represent missing pull-request target-branch metadata explicitly and treat the affected operation as a terminal skip rather than a retryable failure. Continue rejecting malformed, nonempty branch references.
An alternative is to recover the branch through an additional Azure DevOps pull-request API call, but that adds network cost and another failure mode.
Validation
Add focused tests proving that:
- A pull-request build with neither target-branch field does not throw during mapping.
- Build analysis and queue insights complete the work item without downstream analysis when the target branch is unavailable.
- A malformed, nonempty target branch is still rejected.
Impact
Build Insights observed 65
System.ArgumentExceptiontelemetry rows across 51 operations in a 24-hour production window. All selected exceptions correlated exactly with failed work-item telemetry. Affected work included build analysis and queue insights, and some work items exhausted attempt 3.No raw telemetry, operation identifiers, customer data, or credentials are included here.
Evidence
BuildDataProvider.GetTargetBranchchecks Azure DevOps build parameters forsystem.pullrequest.targetbranch, then checksTriggerInfoforpr.targetBranch. Some pull-request builds contain neither value. The method throws while mapping the Azure DevOps build into the domain model, before processors can apply their existing unavailable-target-branch handling.The missing metadata remained consistent across retries. Retrying therefore repeated the same failure rather than recovering.
Likely root cause
A stable unsupported-input condition is represented as
ArgumentExceptionand handled by the generic work-item retry path. Confidence is high.This hypothesis would be disproved if the original Azure DevOps payload contained either supported target-branch field, or if later attempts retrieved different metadata.
Suggested behavior
Represent missing pull-request target-branch metadata explicitly and treat the affected operation as a terminal skip rather than a retryable failure. Continue rejecting malformed, nonempty branch references.
An alternative is to recover the branch through an additional Azure DevOps pull-request API call, but that adds network cost and another failure mode.
Validation
Add focused tests proving that: