Update StackExchange.Redis from 2.0.x to 2.1.0

[tebeco]

Summary of the changes :

• Just update StackExchange.Redis to 2.1.0
  Release note : https://stackexchange.github.io/StackExchange.Redis/ReleaseNotes

Related to #20040 but does not seems to address it ...

Details

After trying to work on #20040 i saw multiple post from @NickCraver and @mgravell pointing out that 2.1.0 was just released

As i understood from existing issues, one of the changes is "better error msg" <==== i though it would have helped me understanding #20040

Given the fact that it seems to be related to a massive list of potential issues, is it worth updating it ?
eg:

• PhysicalBridge always returns NoConnection after exception during message write / connection flush StackExchange/StackExchange.Redis#1374
• It also enables supports for IAsyncEnumerable which might be useful somedays (or not) in Microsoft.AspNetCore.SignalR.StackExchangeRedis

[dougbu]

@anurse can you or someone on your team make the call on this minor version jump❔

[mgravell]

Can I suggest a title edit? ServiceStack.Redis <> StackExchange.Redis; I appreciate the names are confusing.

We're also currently investigating a possible lead on additional stability tweaks (IIRC one of the SignalR tests reliably fails, which is valuable to us).

[tebeco]

oO my... sorry i needed to sleep when typing, too bad i can't rename the branch name too
(TIL: can't find a "rename issue" on mobile app)

[NickCraver]

I kindly suggest holding off another minor release here (happy to follow-up and ping here when it's done). We're investigating a few more reports that look like a different issue (e.g. the config is bad and we were never able to connect). I'm adding some counters and improving error messages so we can help users better when that happens.

An unfortunate side-effect of the Azure advice (it's warranted) with AbortOnConnectFail = false (e.g. keep trying if we don't connect immediately...maybe the service isn't up) is that it keeps happening in the background asynchronously. This creates a secondary/downstream issue of trying to use a connection that isn't connected in a race situation especially at startup. Annnnnnd it creates another: you could have bad config (endpoint, password, anything) and it'll never connect. You'll just get this error. That's why we by default to abort connecting and throw up front before (AbortOnConnectFail = true).

I'm talking to Marc and want to ping the Azure Redis team and re-think the advice and defaults we're giving here. I believe based on going through hundreds of reports across the past 2 years that this scenario is not uncommon: "you just had bad config". But users are confused about it. I want to improve that somehow and have the lib bump here benefiting from that.

[tebeco]

thx a lot for the insight @NickCraver

I'l let @dougbu and @anurse decide if i should let this PR open or no
i not sure it's possible to move it back to DRAFT

not sure how long open PR should stay on the repo

[dougbu]

I'll let @dougbu and @anurse decide if i should let this PR open or no

This is @anurse's call

not sure how long open PR should stay on the repo

We do not have firm rules about PR lifetimes. Don't worry about leaving this open for a good while.

[analogrelay]

I trust @NickCraver and @mgravell 's advice here. I think we should hold off for now.

We do not have firm rules about PR lifetimes. Don't worry about leaving this open for a good while.

Honestly, I would prefer we close it if we know we aren't taking it in it's current form. We've been trying to drive down open PRs, at least in my areas. It's easy enough to re-open or open a new one later if @tebeco keeps their branch around and rebases it when we have a new candidate to upgrade to.

[tebeco]

fine for me ;)

I just have to find a way to keep being in touch with @NickCraver and @mgravell to know when to re-create a PR here

[analogrelay]

I'll create an issue to look back on this a little later in the 5.0 cycle too, so we don't completely miss it ;).

[NickCraver]

We've added more diagnostics and better error messaging (to distinguish between the earlier cases) in the 2.1.23 release (currently on MyGet). We'll get that dogfooded on Stack Overflow this week. It also adds more detection for binding redirect failures (at the pipelines layer) to users are alerted to more failure cases due to that.

I'd say poke me in 1-2 weeks please - we'll have been in prod for a while and get more follow-ups from users testing it. I'd like positive reports on better issue resolution then advise a bump here for all users to benefit.

We're also going to get a hold of the Azure Redis team and sanity check some previous decisions and see if tweaking some defaults makes sense (e.g. we have a theory about Redis instances going to "sleep" we think may be affecting some users...).

[analogrelay]

Filed #20076 - I'll put this down for preview4 (since preview3 is locking down soon).