sails: connect-redis crash Sails if Redis is down and Redis password is configured

Sails version: 0.12.3 Node version: 6.3.0 NPM version: 4.0.5 Operating system: Windows 10 64 bit


Make sure your connect-redis is properly built and installed (if using Windows, you probably need the very most recent NPM: npm install npm@next -g, besides Windows build tools https://github.com/felixrieseberg/windows-build-tools ) Setup Redis server on a separate machine Configure Redis server to require a password Configure Sails sessions to use connect-redis; add the proper password value Lift Sails All works fine Take Sails down Take Redis server down Lift Sails Sails will lift, but after a while it will crash. Crash will happen if you try to browse your site too. Error thrown:

node_modules\connect-redis\lib\connect-redis.js:95
          throw err;
          ^
 AbortError: Redis connection lost and command aborted. It might have been processed.

Go to the connect-redis.js at that line and you will see

if (options.pass) {
      this.client.auth(options.pass, function (err) {
        if (err) {
          throw err;
        }
      });
    }

Go back to your Sails configuration, remove the password key from the session configuration (pretend your Redis server doesn’t require a password). Keep your Redis server down. Lift Sails. Everything works. No crash. Of course, you can’t say the sessions are being handled by Redis, but at least the server is not crashing.

Previous closed issue related to this issue:

https://github.com/balderdashy/sails/issues/2276

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 25 (18 by maintainers)

Most upvoted comments

@sgress454 Nice! I didn’t know that, great. Now I can simplify our RBAC hook 😛

@luislobo interesting! Bear in mind that any key you put on a route like that will automatically be merged into req.options, so you don’t necessarily need a separate hook to implement what you’re doing. You can do this right now:

// In `config/session.js`
isSessionDisabled: function (req){

  if (req.options.useSession === false) {
    return false;
  }

   // other validations here

  // Otherwise, don't disable sessions.
  return;

}

@mikermcneil yeah, I was checking just that. One thing that we are doing, is extending the routes config using with our own keys, for different stuff, like for example, setting up rbac stuff:

DISCLAIMER: this is not official nor available in Sails, it’s a custom hook used internally that handles that

'post /user': {
    controller: 'user',
    action: 'create',
    rbac: {
      'admin': {
        when: function (params, next) {
          return sails.hooks.rbac.canCreateUser(params, next);
        }
      }
    }
  },

DISCLAIMER: this is not official nor available in Sails, it’s a custom hook used internally that handles that

So, in Sails 1, if you add session:false to a route config, you can easily implement it:

// In `config/session.js`
isSessionDisabled: function (req){

  if (_.has(sails.config.routes, req.route.path)) {
    return _.get(sails.config.routes[req.route.path],'session',false);
  }

   // other validations here

  // Otherwise, don't disable sessions.
  return;

}

Even some temporary internal network problem could drop sails. Would there be a way to segment the apps into redis-dependent and non-dependent parts? Maybe in the routes configuration?

@cburatto to be clear, this should only crash Sails during lift-- so in other words, it’s like Sails failed to lift, except the error message isn’t as good.

As for Redis failures crashing your app post-lift – that should be 100% resolved, at least in Sails v1