I think there's a race in ReconfigureAsync with clusters here where the last subscription to finish is left out...but not seeing it yet. Tests show it over and over, though.

Trying to get this to register in VSTS...

This allows running VSTS builds in 1 step.

GitHub conflict editor hosed this. Blah.

Not sure why this is failing...we need more info. It could be socke exhaustion on the box.

It appears we just never use this property anywhere and never noticed, but users did long ago. See #229 for details.

Also adds some testing around this. While this may be considered a breaking change, I'm really going to err on the side of this is a plain on bug fix on a rarely used property. This doesn't impact any existing tests.

This is a known failure - will try to address next week.

This could be a terrible idea, but I hope it helps isolate failures and increase stability a bit.

Multiple runs aren't safe here...new key filter is.

This is a race in the implementation due to pub/sub order and locking. Just improving the test to help illustrate it.

High delays before weren't fixing the test on a stressed server, they were allowing the interval-based reconfiguration to mask the failure.

Though we lock on servers here, serverSnapshot is iterated in more cases, this reconfiguration iteration leaves null entries in the array causing downstream issues.

This is tricky, because you can't write to it if there's no test, xUnit goes boom. We can't write to the ITestOutputHelper here without failing the suite depending on the race.

But still, want to avoid dumping to the console and build log directly.

The jitter was causing 01:00:00 vs 00:59:59.9999967 due to the time between calls under load, but when you simplify the math: it should always be zero no matter what.

Also adds a delay after for restoration.

More dupe runs issues.

This test failing hoses many that follow..

It occurs to me the basis of multi-testing the same keys are fundamneally problematic, hidden behind the Me() call - at least fix those in a batch here.

So this one is fun. Windows caches DNS, including a miss. The second test runner will fail synchronously in the Socket.BeginConnect() call due to the DNS looku failing immediately (no need to wait!). This beaks our assumptions of it failing asynchronously in these tests.

If this resolves the issue, we'll put a wrapper in the .BeginConnect() call to capture and recognize the SocketException "No such host is known" and return the RedisConnectionException users expect.