-
Notifications
You must be signed in to change notification settings - Fork 31
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
Rescue OpenSSL errors in Client#transaction #83
Conversation
This feels like a similar category of socket/network-related errors that could be handled in a similar fashion.
Hmm... this might still be a little off the mark. It seems like something must be calling the OpenSSL shutdown function for |
Make sure you have a recent Redis version packaged with Faktory. I’m not sure which version is packaged in the Docker image. |
I know there is a OpenSSLshutdown issue with earlier versions of Redis 6.2.x. |
This issue is between the Faktory Ruby client and server so I guess a Redis upgrade isn’t exactly relevant but make sure you upgrade your Ruby version to get the latest OpenSSL fixes. I can see this happening if you have an old Ruby version using a newer OpenSSL v3. |
Good tips, thanks! I will check those versions. We're on Ruby 3.2.2 so not the latest but not too old either. |
Looks like the Docker image does have a pretty recent version of Redis:
And we're on Ruby 3.2.2 with OpenSSL 3.1.0 gem, and OpenSSL 3.0.2 apt package (Ubuntu 22.04). So pretty recent versions although not the latest. |
I think this will break if the user is not using TLS because we conditionally require OpenSSL. That error class won't exist. |
Ah good call, I didn't realize it was conditionally required. Thanks for fixing that! |
This feels like a similar category of socket/network-related errors that could be handled in a similar fashion.
This may help resolve the issues experienced in #51. Ultimately it probably indicates a network issue, but it seems like right now things get into a bad state if this exception is raised.
I don't know if e.g. jobs would get double-pushed if this handler were to handle this exception, but that is probably preferable to a process getting into a bad state until it's killed.