Problems with Azure Devops Reporter
See original GitHub issue- This issue is blocking
- This issue is causing unreasonable pain
As I’ve written up in https://github.com/dotnet/core-eng/issues/13026, we introduced a threading bug in https://github.com/dotnet/arcade/pull/7310/files that can crash the reporter. It may be difficult to intentionally reproduce this problem since it kind of relies on actually doing the reporting, but we can inspect the code or just revert the lock
part of the change and instead just do the “don’t let it pass if it doesn’t finish” part of the change.
Issue Analytics
- State:
- Created 2 years ago
- Comments:15 (15 by maintainers)
Top Results From Across the Web
Troubleshoot access, permission issues - Azure DevOps
Find helpful troubleshooting information for resolving access and permission issues in Azure DevOps.
Read more >Troubleshoot pipeline runs - Azure DevOps
Check the Azure DevOps Service Status Portal for any issues that may cause a service degradation, such as increased queue time for agents....
Read more >Resolve common Azure DevOps Office integration issues
Learn how to resolve common integration issues that occur with Azure DevOps Office integrations.
Read more >Azure DevOps Service Status
If you're experiencing a problem with any of our Azure DevOps Services, you can check the service health to determine if we're already...
Read more >Azure DevOps Support
Get fast help for Azure DevOps Services. Our virtual assistant can answer questions, troubleshoot, perform a region move, or log an incident.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@ericstj I may take some stabs at this one tomorrow but it’s much harder than simply adding retries to AzDO calls.
Just had a great conversation with @safern and he made a very keen insight. Specifically, if we just update the arcade reporter behavior to just return the real, not lying exit code when Azure Devops reporter fails, it’s easy to implement and gives us the best of both things; when reporting fails, the work item still can pass, and when the work item fails and reporting fails, we still fail the check, e.g.: