go - azadmin is failing consistently with a weird checkout error

[scbedd]

See this failing pipeline for an example failing build.

Need to jump on this priority as it is blocking a release.

[benbp]

@scbedd looks like the failure is related to coverage, not checkout? Or maybe I'm looking at a different pipeline result. For coverage the values get set here: https://github.com/Azure/azure-sdk-for-go/blob/main/eng/config.json#L102

[scbedd]

@benbp I hadn't dug in yet, @gracewilcox was just over asking. The build failure that she had me looking at included a checkout failure. I really haven't dug in at all yet though, just created a tracking item and went back to what I was doing. Will dig later today.

[gracewilcox]

@scbedd looks like the failure is related to coverage, not checkout? Or maybe I'm looking at a different pipeline result. For coverage the values get set here: https://github.com/Azure/azure-sdk-for-go/blob/main/eng/config.json#L102

It's citing a code coverage issue since TestRoleDefinitions and TestGetSettings is failing, therefore it's not meeting code coverage minimum. It says that "Recording ID was not returned by the response."

[scbedd]

Alright, so I had a chat with grace, and we think we understand why we are seeing this Admin/ResetSanitizer only now.

1. It's not a restore conflict. That is addressed by my test pr here which just removes any possibility of race-condition during restore.
2. After we fix the restore, we actually see a new error. This new error is because the azadmin package is actually multiple packages. As each package finishes or starts, they fire session-level Admin/Reset at the proxy. Because there are multiple packages, we fire multiple Admin/Reset requests, and those may or may not stomp on currently active playback sessions.

This multiple packages being handled by one proxy while they each assume they're the only one running in the session is the reason why we only see this TYPE of failure for azblobs, azfile, or azadmin. These are the only package within packages we have for go!

I will resolve the weird checkout error in #6484, but that will just reveal this other reset error.

I will close this issue as completed with the other PR, and work with the go team to make each package invoke it's own test-proxy for the go team.

[scbedd]

We have set an override within the go repo to the previous version of the proxy. We'll unpin while we fix it.