Why no support for unavailable cache backend

[FGRibreau]

Hello !

I may have miss something, but wouln't it be great to let us specify if we want catbox to fallback on the handler if the cache backend is not available, because currently:

• the hapi server can't start if catbox was not able to start cache backends
• (and even if we change the catbox-redis client code to be silent on errors for instance) if the cache backend is temporarily unavailable the client will receive a "disconnected" error instead of (optionally) directly calling the route handler

internals.Client.prototype.get = function (key, callback) {

    if (!this.connection.isReady()) {
        // Disconnected
        return callback(Boom.internal('Disconnected'));
    }

[hueniverse]

Getting a ready cache is part of the hapi start contract. If the cache is not available, it is considered critical issue that should stop a process. I don't see this as a meaningful use case.

[FGRibreau]

Ok @hueniverse, so just be sure to understand the decision. The hapi team does not think it's important to make hapi resilient of cache backend unavailability?

Indeed, in my case it's not an option to not have hapi resilient on this side since I can afford to support request without caching

[Marsup]

Are you saying that if the cache is unavailable you never reach the handlers ? I think it's only used explicitly or through server methods now.

I have to agree that its unavailability shouldn't keep the server from functioning, but it can also be very hazardous for you service if you rely on it for a multi-node deployment.

[hueniverse]

First, this is not a "team decision". It is my opinion.

Second, there is a big difference between startup and runtime. We can add an option to basically report but ignore cache init errors but that is going to be exactly what it is. You will call server.start() or server.initialize() and instead of getting an error back, you will get a success response and the error will be logged via the normal server logging events.

This is possible but it also mean you will not have a great way to react to this issue. It will basically be no cache for the duration of this process. There is not going to be an easy way to recover from that since the initial state will unknown.

If this is what you want, open an issue in hapijs/hapi. I am not sure I'll have the time to implement it, but I'll consider PRs there.

[FGRibreau]

Are you saying that if the cache is unavailable you never reach the handlers ?

@Marsup Indeed, that's the current behavior of catbox/hapi, something that a user may want to be able to deactivate.

I have to agree that its unavailability shouldn't keep the server from functioning

Indeed, it depends on the context, but in our case it did not make sense to let a cache backend unavailability stop our server from functioning.

We can add an option to basically report but ignore cache init errors but that is going to be exactly what it is.

I'm all for the fail-fast approach, I perfectly anticipated the issue with monitoring, however in some case it's not desired.

[devinivy]

As an interim solution, I expect one may be able to write a wrapper that brings this functionality to any catbox engine.

allowBadConnect(require('catbox-redis'))

[lock[bot]]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.