Integrity constraint violation when using database session driver

[thewinterwind]

Experienced this in 5.0 and 5.1

MySQL version: 5.6
Forge provisioned server.

We use Galera Cluster for MySQL, but each site reads and writes from only one database. I don't think that would have anything to do with this error. I used artisan session:table to create the table so everything is standard schema-wise. Happens quite intermittently, about once per day.

Illuminate\Database\QueryExceptionGET /diaz/edit
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '4c1698dcfe5da87c5f77c90592855490817e575d' for key 'sessions_id_unique' (SQL: insert into `sessions` (`id`, `payload`, `last_activity`) values (4c1698dcfe5da87c5f77c90592855490817e575d, YTo1OntzOjY6Il90b2tlbiI7czo0MDoid1NLSjlmNGFxUml4RkowRVVkU0M3UjhNdldhWlZEY2hwTDhrbEU3YSI7czo3OiJtZXNzYWdlIjtzOjI2OiJMb2dpbiB0byBlZGl0IHlvdXIgcHJvZmlsZSI7czo1OiJmbGFzaCI7YToyOntzOjM6Im5ldyI7YTowOnt9czozOiJvbGQiO2E6MTp7aTowO3M6NzoibWVzc2FnZSI7fX1zOjk6Il9wcmV2aW91cyI7YToxOntzOjM6InVybCI7czozNzoiaHR0cHM6Ly9tYW5pbGEuZXNjb3J0cy5saWZlL2RpYXovZWRpdCI7fXM6OToiX3NmMl9tZXRhIjthOjM6e3M6MToidSI7aToxNDM0MTY4Njc0O3M6MToiYyI7aToxNDM0MTY4Njc0O3M6MToibCI7czoxOiIwIjt9fQ==, 1434168674))

[rkgrep]

Is it possible that insert quieries are not written immediately but with some latency?

[thewinterwind]

yes but not much. I am not caching config.

[GrahamCampbell]

You probably need to cache config. That fixes most issues I see like this.

[ibrasho]

I'm using config:cache but I still see this issue every day or so.
We still relay on dotenv to populate server variables, so this might be the issue.

[rkgrep]

Why do you think it is a config cache issue?
I guess there may be some latency between sending response (with session ID) and app termination (when session is being saved to databse).

For example:

1. User sends request - session id created (session->exists == false)
2. User gets response (with generated session id).
3. Some ajax or another request catches session id (session->exists == false as the first request is not finished - session is not written).
4. One of requests terminates app (session written to database with INSERT)
5. Another request terminates with INSERT statement again (because session->exists is false in both cases)

Otherwise it may be database INSERT query latency so the second request executes SELECT before insert finishes.

[fer-ri]

Happened to me now after switched to database driver for session .. any idea?

Thanks

ping @taylorotwell

[mgrimard]

I am experiencing the issue as well, using the default session build with the DB.

[fer-ri]

👍

[deanmraz]

@GrahamCampbell why close this ticket, seems like lots of people are having issues with this problem and continue to have this problem. I think the issue lies in the database driver -> save method.

[taylorotwell]

This needs reopening.

On Jan 28, 2016, 5:18 PM -0600, Dean Mnotifications@github.com, wrote:

@GrahamCampbell(https://github.com/GrahamCampbell)why close this ticket, seems like lots of people are having issues with this problem and continue to have this problem. I think the issue lies in the database driver ->save method.

—
Reply to this email directly orview it on GitHub(#9251 (comment)).

[taylorotwell]

Does anyone have a solution?

On Jan 28, 2016, 5:18 PM -0600, Dean Mnotifications@github.com, wrote:

@GrahamCampbell(https://github.com/GrahamCampbell)why close this ticket, seems like lots of people are having issues with this problem and continue to have this problem. I think the issue lies in the database driver ->save method.

—
Reply to this email directly orview it on GitHub(#9251 (comment)).

[deanmraz]

Deployed this fix to my environment today. I will let you know if that resolves the issue.
#12059

[nolros]

@taylorotwell @GrahamCampbell

Laravel version 5.2.37

I've seen a number of these session integrity issues show up on laracasts, stackoverflow, etc. I ran into the same issue today and able to replicate to some degree. It seems to a session DB related issue vs. session file. To be honest it is not really a bug but a dev issue that can be solved with middleware. That said given the norm of multi device it might be something you want to look into, but unsure if even that applies.

REPLICATE: Let’s say you have a home.blade.php and second page called register.blade.php a route ‘/register’ which yields content from home. If you load /register from lets say from a MAMP stack everything will work fine as expected. Now while you still have that session, open a new browser tab. Make a copy of home.blade.php , lets say debug.blade.php which again yields to the same register.blade.php a route ‘/register’ and now if you load /register it will load register and will create the duplicate session id. Now if you go back to original tab and attempt to load register or you will get a DB session integrity duplicate issue. Which is why a number of bug complaints are login / logout related as I suspect is because they are directing to a different (duplicate) home page while still using the same session. Unsure what is causing the duplicate issue i.e if it is csrf token / session / DB session / home page issue.

Hope his helps.