-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Seems like FailureType is not correctly indicating authentication error #2362
Comments
Which version of the library are you using? For info: this was improved in 2.6.66+, release notes and links here: https://stackexchange.github.io/StackExchange.Redis/ReleaseNotes#2666 |
I am using 2.6.90 version and the the screenshot is of the same code. ExceptionFactory seems to be setting same failure type in case of all UnableToConnect errors. |
Can you post the actual error message and type you're seeing? Look at this from my view: all I have is a screenshot of code, I'm not sure what error you're seeing and what you're expecting to see. e.g. "is it including the test about it being an authentication failure?" - give us something to go on here... |
I am trying to handle authentication failures in my code. To test this scenario, when I pass incorrect credentials , I am getting exception with the correct message but the "FailureType" in the exception seems to be not correct . I need a differentiator in case of authentication errors apart from the exception message. FailureType seems to be the correct field for it. But the value getting returned in this case in FailureType is "UnableToConnect" which I felt was incorrect as the enum has a better alternative to represent authentication failure. |
I agree with the @tavisca-manpreet point, enum StackExchange.Redis.ConnectionFailureType already have |
Hey y'all - I'm just slammed with actual work stuff this week (this isn't the thing we're paid for :)) but wanted to say yes: completely agree. I haven't gotten a chance to look at this (hopefully later this week but we'll see how it goes), but I appreciate the clarification and additional detail. The request absolutely seems reasonable. Adding to the message it was because of auth and not a generic connection failure was something I only recently did a few months ago, and likely missed this aspect - will take a peek and report back. |
I added to the string message a while back but we should set the ConnectionFailureType more specifically as well here so that people can handle it much easier. Fixing!
Had to wait on some builds this morning so poked at how big this is - super minor to adjust/test, fix is up here: #2367 |
Thanks @NickCraver for the quick fix. |
@tavisca-manpreet one note here: you could check the type on InnerException if you wanted until this is available on NuGet, in case that unblocks :) |
Hi @NickCraver, Thanks |
I'm not sure how your connection is being created, but sslprotocols being specified while also turning SSL off is curious - any idea what's going on there? |
Hi @NickCraver |
No description provided.
The text was updated successfully, but these errors were encountered: