Please can you gist the stack-trace?

sure, here is the stack-trace: http://gist.github.com/230548

I noticed the session_id pass to Rack::Session::Redis#set_session was nil
If we regenerate_sid in set_session

 40       def set_session(env, session_id, new_session, options)
 41         @mutex.lock if env['rack.multithread']
 42         session = @pool.get(session_id) rescue {}
 43         session_id = generate_sid if session_id.nil?
 44         if options[:renew] or options[:drop]

logout will be smooth as normal, but there is another problem, the old session will not deleted.

I got it work.

It end up to set :renew and :drop to options:

      # reset_session
      request.session_options[:renew] = true
      request.session_options[:drop] = true

I not confident is this gonna broken in the future due to the correctly API seems to be request.reset_session, I also lookup into Rack::Session::Memcache, Rack::Session::Tyrant, the implementation seems no different to me.

Anyway, as long as it works, I'm happy.

tnx for your help and your great work.

Err. The flash was broken, behavior was the same as #issue/3 Rails flash is getting stuck

I will try to investigate, are you sure this error only affects the redis-store? Did you tried to switch to another Rails bundled store: ie. file-system, or memcached.

I switched to my own implementation (at a higher level in the code base, similar to the built in memcache_store) and the flash wasn't sticky.

I'll try to see if I can't make a simple Rails app that duplicates this...

I also am experiencing this issue after switching my sessions to redis-store.

This probably isn't the correct way to fix the issue, however, it does work and may shed some more light on why this is happening. I think the problem is that new['flash'] != old['flash'] isn't comparing correctly because of the way flash (in Rails) marks keys as dirty once they are used.

lib/rack/session/redis.rb: line 62:

def merge_sessions(sid, old, new, cur=nil)
  cur ||= {}
  unless Hash === old and Hash === new
    warn 'Bad old or new sessions provided.'
    return cur
  end

  delete = old.keys - new.keys
  warn "//@#{sid}: dropping #{delete*','}" if $DEBUG and not delete.empty?
  delete.each{|k| cur.delete k }
 
  update = new.keys.select{|k| new[k] != old[k] }
  warn "//@#{sid}: updating #{update*','}" if $DEBUG and not update.empty?
  update.each{|k| cur[k] = new[k] }
  # ===> BEGIN fix
  cur['flash'] = old['flash'] unless old['flash'].nil?
  # ===> END fix
  
  cur
end

For Rails users here is a quick monkeypatch that should get flash working:

in config/initializers/session_store.rb add this to the bottom:

module Rack
  module Session
    class Redis
      private; def merge_sessions_with_flash_fix(sid, old, new, cur=nil)
        cur = merge_sessions_without_flash_fix(sid, old, new, cur)
        cur['flash'] = old['flash'] unless old['flash'].nil?
        cur
      end
      alias_method_chain :merge_sessions, :flash_fix
    end
  end
end

Sorry for the delay, I'm digging into the problem, and the same issue seems to affect Rack::Session::Memcache.

When the redirect is being performed, the new object still has the flash key, so the problem isn't in the merge_sessions algorithm.

The problem is in ActionController::Flash::FlashHash#sweep, when the session store is set on CookieStore (default), it properly handle the @used hash, so the flash keys are deleted after the first use.

@used[:notice] # => false on the first request, then true on subsequent (CookieStore)

@used[:notice] # => It's always false with Redis/Memcache store

As you can see, this prevent the deletion of the key. I'm looking for the root cause and figuring out how to patch it.