-
Notifications
You must be signed in to change notification settings - Fork 17
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
Implement cache client event listeners #6
Comments
For listening to the events from
and then the module that imports and initializes
This works well to listen to the errors and handle those and the app doesn't crash, however, if the app is unable to connect to the client during initialisation itself, these listeners don't get a change to get registered and the app crashes. So far even I haven't found a way to avoid the app from crashing when app is unable to connect while initialising |
anything new on this issue? |
I am stuck on the exactly the same thing :( |
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
I often use console commands for long running jobs such as data migrations. I also have some workers that run in a headless Nest application.
In both instances, I occasionally have issues where the Redis cache client throws an
ETIMEDOUT
error. This has the effect of crashing the entire program, and no amount of try/catching seems to catch the error.I believe the correct way to deal with this is to set up an event listener on the redis client itself, however I have not been able to find a way to get the client once it's been instantiated.
Unless I'm missing something, there is no opportunity to set up an error listener in the following example code:
Describe the solution you'd like
Being able to grab the client and set up listeners somewhere before it is used seems to be important. Ideally one could set up listeners at various touchpoints:
.on()
method) at runtimeEvent listeners may be specific to the Redis client, in which case this would be a better request for that library.
Teachability, documentation, adoption, migration strategy
A possible API
Setting up listeners at config time:
Setting up listeners at run time
What is the motivation / use case for changing the behavior?
As it stands, it's impossible to react to events emitted by the underlying client.
The text was updated successfully, but these errors were encountered: