For Azure Storage, a conflict happens in the tests:
Unable to create staging queue 'delays879ce3b51b70b8ef2322569731cec26a220776fastaging'. Exception message 'Conflict'
As part of the migration process, it actually creates a table (so the error message "staging queue" is misleading) named delaysXXXXXstaging where the X's are a hash of the endpoint name. This is actually driven by the delayed delivery capability of the Azure Storage Queues transport, with delaysXXXXX being a thing used by the transport, and the migration process is only creating something with staging tacked on to the end.
What is currently happening is that the net6.0 tests run and successfully do a migration, and clean up the staging queue. But then the net7.0 tests start running not long after … quickly enough that Azure Tables returns a Conflict exception when the tests try to create a new table with the same name as the very-recently-deleted one.
So even in Visual Studio, running the test again too fast after a success will cause it to fail. The solution is to change the endpoint names. The test conventions only allow doing this by type, where we don't have access to the test context's unique RunId, so the best thing we can do to disambiguate the test runs is to add the .NET version into the endpoint name as well.
For Azure Storage, a conflict happens in the tests:
As part of the migration process, it actually creates a table (so the error message "staging queue" is misleading) named
delaysXXXXXstagingwhere the X's are a hash of the endpoint name. This is actually driven by the delayed delivery capability of the Azure Storage Queues transport, withdelaysXXXXXbeing a thing used by the transport, and the migration process is only creating something withstagingtacked on to the end.What is currently happening is that the
net6.0tests run and successfully do a migration, and clean up the staging queue. But then thenet7.0tests start running not long after … quickly enough that Azure Tables returns a Conflict exception when the tests try to create a new table with the same name as the very-recently-deleted one.So even in Visual Studio, running the test again too fast after a success will cause it to fail. The solution is to change the endpoint names. The test conventions only allow doing this by type, where we don't have access to the test context's unique RunId, so the best thing we can do to disambiguate the test runs is to add the .NET version into the endpoint name as well.