title: NodeJS / express / connect-redis: no error on redis being down; session missing
body: <p>i'm building a web application on NodeJS using express; the session store is a Redis instance which i talk to using <code>connect-redis</code>. the usual bits look like, well, usual:</p>
  
  <pre><code>RedisStore = ( require 'connect-redis' ) express
  
  express_options =
    ...
    'session':
      'secret':   'xxxxxxxx'
      'store':    new RedisStore host: '127.0.0.1', port: 6379, ttl: 2 * weeks
      'cookie':   maxAge: 2 * weeks
  
  
  app = express()
  # Middleware
  ...
  app.use express.cookieParser 'yyyyyy'
  app.use express.session express_options[ 'session' ]
  ...
  </code></pre>
  
  <p>this does work well as such. however, i have not demonized Redis yet. after starting the server (but not Redis) and re-issuing an HTTP request from the browser, the application (apparently, naturally) failed to recognize yesterday's session cookie. to be more precise, the point of failure was </p>
  
  <pre><code>  request.session.regenerate =&gt;
      request.session.user = uid_hint
  </code></pre>
  
  <p>in a login view, and the message was <code>TypeError: Cannot call method 'regenerate' of undefined</code>. now the question is:</p>
  
  <p><strong>(1)</strong> is my impression true that express won't balk at me when i try to use a session middleware that is configured to ask for data on a specific port, and yet that port is not served at all? if so, why is there no error message?</p>
  
  <p><strong>(2)</strong> what is a good way to test for that condition? i'd like a helpful message at that point.</p>
  
  <p><strong>(3)</strong> given that a DB instance may become unavailable at any one time—especially when it is separated by a network from the app server—what are best practices in such a case? fall back to memory-based sessions? refuse to serve clients?</p>
  
  <p><strong>(4)</strong> let us assume we fall back on another session storage mechanism. now all existing sessions have become invalid, right? unless we can decide whether a given signed SID coming in from a client is computationally valid in the absence of an existing record. those sessions will still be devoid of data, so it's not clear how useful that would be. we might as well throw away the old session and start a new one. but how? <code>request.session = new ( require 'express' ).session.Session()</code>, maybe?</p>
  
  <p><strong>Bonus Points</strong> <em>(i'm aware some people will scoff at me for asking so many different things, but i think a discussion centered on sessions &amp; cookies should include the below aspect)</em></p>
  
  <p>thinking it over, i'm somewhat unhappy i'm using Redis at all—not because it's Redis, but because i have yet another DB make in the app. a theoretical alternative to using a session DB could be a reasonably secure way to keep all session data (<em>NOT</em> the user ID data, <em>NO</em> credit card numbers—just general stuff like which page did you come from etc) within the cookie. that way, any one server process can accept a request and has all the session data at hand to respond properly. i'm aware that cookie storage space is limited (like 4kB), but that might prove enough still. any middleware to recommend here? or is the idea dumb / insecure / too 1990?</p>