Session started in order to track cache hits

[ztmztm]

Problem Statement

The recent mods, version 4.15.2 or 4.15.3, added a behavior that might create some problems to some people.
It looks like hitting a cache key now makes Sentry start a session, which might be undesirable for some long-lived processes like the Laravel Horizon supervisor and master process.

What I experienced is that "all of a sudden" (that is after upgrading Sentry packages via composer), my deploy script doing the "horizon:terminate" stoppeed working. After A LOT of researching, I found out that Sentry was actually starting a session in order to gather data subsequently to a cache hit. My session storage was the DB (I'm going to change it) and a firewall is dropping the TCP connections after 60 mins, so the long-lived processes were stuck forever waiting to close a connection that wasn't responding and that I did not expect to have started at all.

Solution Brainstorm

Please consider the need to start a session. I'm not a great expert, so I'm not going deep, but maybe that part can be ignored is a session has not started yet.
I understand if you decide to not do anything, because you believe everything's working as expected.

[linear]

LARAVEL-41

[stayallive]

We tried to be really careful with this:

sentry-laravel/src/Sentry/Laravel/Features/CacheIntegration.php

Lines 263 to 271 in 7c81b41

	/** @var Session $sessionStore */
	$sessionStore = $this->container()->make('session.store');
	// It is safe for us to get the session ID here without checking if the session is started
	// because getting the session ID does not start the session. In addition we need the ID before
	// the session is started because the cache will retrieve the session ID from the cache before the session
	// is considered started. So if we wait for the session to be started, we will not be able to replace the
	// session key in the cache operation that is being executed to retrieve the session data from the cache.
	return $sessionStore->getId();

I can see an improvement that on CLI we don't even have to try getting the session ID since that will obviously never work but it should never start a session. Or at least that was never the intention.

So I am trying to understand what is happening exactly. Can you share your composer.json and config/session.php so I can try to replicate what you are seeing?

[ztmztm]

composer.json

session.php

Session vars are not defined in the env, so they are all default (now I've defined the storage to be Redis instead of DB).
Some of the libs in composer will require a password, but they are hopefully not affecting this behavior.

This is the stack trace that helped me to understand what was going on:

[2025-10-28 12:56:02] staging.INFO: DB Connection Trace for 98544: #0 /var/www/html/vendor/laravel/framework/src/Illuminate/Session/SessionManager.php(108): App\Application\DB\DatabaseManager->connection(NULL)
#1 /var/www/html/vendor/laravel/framework/src/Illuminate/Session/SessionManager.php(95): Illuminate\Session\SessionManager->getDatabaseConnection()
#2 /var/www/html/vendor/laravel/framework/src/Illuminate/Support/Manager.php(106): Illuminate\Session\SessionManager->createDatabaseDriver()
#3 /var/www/html/vendor/laravel/framework/src/Illuminate/Support/Manager.php(80): Illuminate\Support\Manager->createDriver('database')
#4 /var/www/html/vendor/laravel/framework/src/Illuminate/Session/SessionServiceProvider.php(52): Illuminate\Support\Manager->driver()
#5 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(952): Illuminate\Session\SessionServiceProvider->Illuminate\Session\{closure}(Object(Illuminate\Foundation\Application), Array)
#6 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(832): Illuminate\Container\Container->build(Object(Closure))
#7 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1078): Illuminate\Container\Container->resolve('session.store', Array, true)
#8 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(763): Illuminate\Foundation\Application->resolve('session.store', Array)
#9 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(1058): Illuminate\Container\Container->make('session.store', Array)
#10 /var/www/html/vendor/sentry/sentry-laravel/src/Sentry/Laravel/Features/CacheIntegration.php(264): Illuminate\Foundation\Application->make('session.store')
#11 /var/www/html/vendor/sentry/sentry-laravel/src/Sentry/Laravel/Features/CacheIntegration.php(289): Sentry\Laravel\Features\CacheIntegration->getSessionKey()
#12 /var/www/html/vendor/sentry/sentry-laravel/src/Sentry/Laravel/Features/CacheIntegration.php(90): Sentry\Laravel\Features\CacheIntegration->replaceSessionKey('cron-schedules')
#13 /var/www/html/vendor/laravel/framework/src/Illuminate/Events/Dispatcher.php(459): Sentry\Laravel\Features\CacheIntegration->handleCacheEventsForBreadcrumbs(Object(Illuminate\Cache\Events\CacheHit))
#14 /var/www/html/vendor/laravel/framework/src/Illuminate/Events/Dispatcher.php(287): Illuminate\Events\Dispatcher->Illuminate\Events\{closure}('Illuminate\\Cach...', Array)
#15 /var/www/html/vendor/laravel/framework/src/Illuminate/Events/Dispatcher.php(267): Illuminate\Events\Dispatcher->invokeListeners('Illuminate\\Cach...', Array, false)
#16 /var/www/html/vendor/laravel/framework/src/Illuminate/Cache/Repository.php(710): Illuminate\Events\Dispatcher->dispatch('Illuminate\\Cach...')
#17 /var/www/html/vendor/laravel/framework/src/Illuminate/Cache/Repository.php(127): Illuminate\Cache\Repository->event(Object(Illuminate\Cache\Events\CacheHit))
#18 /var/www/html/vendor/laravel/framework/src/Illuminate/Cache/CacheManager.php(453): Illuminate\Cache\Repository->get('cron-schedules')

[stayallive]

Right, okay I see. It indeed does not start a session but creating the session driver results in a connection being opened with the database. This is not ideal and should be done when it's needed but I can see why this happens. Either way we can improve this on our side anyway. I'll cook up a PR, thanks for the excellent info that really helped pinpoint this quickly and is much appreciated!