I am not 100% sure if this is a symfony bug because I am using FoSUserBundle, but from my debugging it seems to be a symfony error.

The Symfony Session caller saves two sessions on authentication. One of them is a blank session with an array that looks like an empty _sf2_attributes array, and the other is the actual session. The PHPSESSID cookie is then changed to the new, different session id.

Technically, everything works. I am able to authenticate my users. but my redis cache is double the size it needs to be and Im starting to get short on memory. I want to get rid of these duplicate keys.

I have also tried memcached and file storage ontop of sncRedisBundle. They both also produce double sessions when authenticated. So I do believe it is a symfony issue.

You can see this in the logs by watching for the REDIS commands being logged by SncRedisBundle (the memcache and file storage do not have debug logs)
Here is some examples

INFO - Matched route "fos_user_security_check" (parameters: "_controller": "FOS\UserBundle\Controller\SecurityController::checkAction", "_route": "fos_user_security_check")
INFO - Executing command "SETNX SESSIONagj232vmqo5ngavqvha016lv1oh00oqe7g22q2eta9skv0lftqr1.lock 1"
INFO - Executing command "EXPIRE SESSIONagj232vmqo5ngavqvha016lv1oh00oqe7g22q2eta9skv0lftqr1.lock 61"
INFO - Executing command "GET SESSION:agj232vmqo5ngavqvha016lv1oh00oqe7g22q2eta9skv0lftqr1"
INFO - User "Austin" has been authenticated successfully
INFO - Executing command "SETEX SESSION:lu735ketuop9dgfh3qitmujge6491274vadfdsdfafadBLAH BLAH SERIALIZED TOKEN CODE HERE;}}i:3;a:0:{}}";}}
INFO - Executing command "DEL SESSIONagj232vmqo5ngavqvha016lv1oqe7g22q2eta9skv0lftqr1.lock" 

As you can see there are two keys being authenticated here:

lu735ketuop9dgfh3qitmujge6491274vadfdsdfafad
VS agj232vmqo5ngavqvha016lv1oh00oqe7g22q2eta9skv0lftqr

I can also show you two session files that have the same thing when using the default session File Handler

sess_bcf61a9jhticgmlec8q32i3vp8hculhojt8e15p20fte8k1  sess_tbtp0p5dsfdl6hu6pelkpr64vlq1sjrlpg4nsuq2fc2l00

Two session files. First one contains empty sf_attributes{} and the second the logged in session.

Something changes after "DEBUG - Write SecurityContext in the session " call. That's how far I have narrowed it down (so...not much)

Anyway this can get fixed? or maybe it's something on my end? I'm not so great with Framework internals, so maybe someone can help me out.