This was an issue with a library update we just pushed out which seemed fine but depending on assembly load order created a race that exposed a binding redirect issue with
System.Numerics.Vectors because the .NET assembly loader is just oh so fun.
The net result was this library which gets a first or second hit between Providence and StackExchange.Redis, when the latter was a binding victim (because it tried to load an older version, 4.1.3, which wasn't there and wasn't redirected). The build produced the latest 4.1.4 so when redis tried to load it had the secondary impact of falling back to a 5 second timeout cap. But, since we connect to many connections and secondaries for redundancy, this resulting in a 100+ second app startup stall (or a chance to have one rather).
In the end, this resulted in a terribly long startup time and still no redis at the end (which is what caused this issue), because the socket pipeline never started up.
The depth of library ref changes (transitive dependencies) here presented no issues or warnings for binding redirects in tooling (VS has a built-in warning for this...but it doesn't trigger) and only presented in prod and only sometimes. We deployed 2 tiers of servers and it wasn't until a follow-up build 20 minutes later that this issue started cropping up on app restarts after the old app domains evacuated.
Binding redirects are the devil. So we're moving to .NET Core where this crap doesn't happen.