The 10-Day Bug Hunt: How a One-Line Fix Taught Me a Big Lesson
For two weeks, every morning I started with a new hope and every evening I left my system with a fresh dose of confusion…
Our team at SoonHost was working on an amazing product that’s going to make a big splash soon.
But during one of the features I was developing, while using the Laravel Reverb package, I ran into a strange problem: users couldn’t join the presence channels.
Before I go on, a quick explanation: these channels allow us to manage users who are inside the channel.
But the problem was that users simply couldn’t authenticate.
I spent about four full days on it.
I tore apart the Broadcast system, rewrote channels, checked logs, ran tests… but no green light appeared. Users still couldn’t authenticate.
Since fixing it was taking too long, with the technical manager’s agreement, we decided to hold this task and fix it in the next sprints.
I moved on to other tasks.
Two days later, while working on an unrelated task (related to SESSION_DRIVER) — guess what? — the authentication problem appeared again!
(To be honest, at that moment I felt like either I should resign or that bug should 😅)
But I didn’t give up.
I started reviewing the software layer by layer; from the entry point to the last service and resource.
Everything worked perfectly… there was no sign of an error.
Then, on day eight, I finally found a small clue.
A glimmer of hope, a little light 💡
I realized that in one layer of the software, users who were authenticating experienced Session ID conflicts.
Something I totally didn’t expect.
(Funny enough, the model was right in front of me, but it was so far out of my mind that I hadn’t even noticed it!)
I spent two more days comparing layers and, on a colleague’s suggestion, created a new test project to analyze the system behavior more precisely.
Finally, on day ten, just a few hours before the end of the workday, I discovered the issue: middleware priority conflicts in session management.
It was simple, yet it caused sessions to be overwritten and authentication to break — basically a disaster 🙂
To be honest, it took 10 days to find the problem, but only 1 hour to fix it.
Now I want to share what I learned with you. I hope no one runs into this problem, but if you do, here’s the solution.
Before diving into the technical part, I want to thank my colleagues who brainstormed with me during this period to solve the problem.
I’m really happy to be part of this team and grateful for all the support 🙂
Technical Notes
In Laravel 12, when using authentication systems like Sanctum, middleware like:
EnsureFrontendRequestsAreStatefulSubstituteBindingsStartSession
are necessary to manage sessions and ensure security.
As the system grows, the number of middleware increases, and sometimes we need to specify middleware execution priority to prevent conflicts and authentication issues.
Example:
->withMiddleware(function (Middleware $middleware): void {
// web group
$middleware->group('web', [
StartSession::class,
ShareErrorsFromSession::class,
]);
// api group
$middleware->group('api', [
Authenticate::class,
SubstituteBindings::class,
]);
// middleware execution priority
$middleware->priority([
StartSession::class,
Authenticate::class,
SubstituteBindings::class,
]);
})
Note: Not paying attention to middleware priority can lead to session and authentication issues.
In this case, I hadn’t included the Session class in the priority, which caused the problem.