-
-
Notifications
You must be signed in to change notification settings - Fork 943
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
Worker won't reconnect to Redis after a connection drop #9252
Comments
Hi, I can confirm this behaviour too, it goes in "unhealthy" mode in Portainer when I update Redis. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hi there, I tested it again, it is still the case with version 2024.4.2 |
Can confirm this happening too. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Still an issue |
Even though not a full solution, this should be handled by the container's healthcheck command that runs |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hi there, Still the case with 2024.8.3 so please don't close the issue 😊 |
Also getting this issue, getting annoying. I have a container to automatically bring up containers not healthy, so it restarts Authentik, and then I get logged out, and the cycle repeats. |
Describe the bug
When the worker disconnects from the Redis container for any reason (in my case, updating the Redis container), the worker fails to reconnect and ends up stuck in an unhealthy state until manually restarted. This also causes it to break its connection with Authentik.
To Reproduce
Expected behavior
The worker should be able to recover from a dropped connection automatically without needing a manual restart.
Logs
Version and Deployment:
Additional context
This issue was reported here a few months ago, but never received any response: #7521
The text was updated successfully, but these errors were encountered: