-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More diagnostic information needed when recording syncing fails #6563
Comments
It definitely outputs it. I'm betting that my ordering of exceptions is off, and that's why you're not getting the initial One recommendation for the .NET CI (aside from addressing this bug) is that it should upload the output of the proxy that we kick as part of the framework. Given the lack of proxy logging I don't really know where to begin to figure out what actually happened here. |
Should it just write to stdout or even stderr? I find that tends to be the easiest to diagnose. For example, I saw a couple of |
Yeah I think this is the problem right here. We're collecting the stderr -> but we're not outputting it onto StdErr pipe -> so the .NET framework isn't seeing that output on stdErr -> you aren't seeing it in CI. |
Addressed on the .NET Test Framework side in Azure/azure-sdk-for-net#37994 |
Related to #6562, it would be great if the test proxy could output more diagnostic information - at least for CIs, if not local dev loops - about what is being sync and any failures that occur. Looking at the failed run, I was not able to tell what had happened. Someone more familiar with the implementation was able to help, but to scale we need more self-diagnosable information available in the CI.
The text was updated successfully, but these errors were encountered: