CodeIgniter 3 session lost when regenerating session ID using Memcached driver only

Question

I am developing a long-running project using the CodeIgniter 3 framework. For several months we have been experiencing issues with sessions being randomly lost. I have updated the framework files to the latest version (3.1.13). It looks like this fixed the issue on the development server, but in production it still exists. But I noticed that now this only happens when the response sends a new session cookie, which happens when the session id is regenerated. When I change $config['sess_time_to_update'] it correctly reflects the required time.

The difference between a development server and a production server is the session driver - it's a file on the development server, whereas in production we use memcached. So I did an experiment and switched the driver to file and the session was no longer lost. I also tried setting it up with the Redis driver and that didn't cause problems either. So it must be a problem with the Memcached driver. But I don't want to trade for another one. There are no errors in the logs. I also checked that the php.ini file and the memcached variables are both with default values.

CodeIgniter v3.1.13, PHP 7.4.3, Amazon ElastiCache for Memcached

This is the configuration:

$config['sess_driver'] = 'memcached';
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 14400;
$config['sess_save_path'] = 'host.com:11211';
$config['sess_match_ip'] = FALSE;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = FALSE;

Any ideas where to look or what to check would be greatly appreciated.

Answer 1

Viewthis answer. Apparently this problem can occur if you set the maximum expiration time of the session to be larger than memcached's expiration limit. In that post, the OP solved the problem by fixing the following configuration variables, which you can try:

define('SESSION_TIME_OUT', x);
ini_set('session.gc_maxlifetime', SESSION_TIME_OUT);
ini_set('session.cache_expire', SESSION_TIME_OUT);
session_start();

Another option is to remove memcached and use a memory-resident sqlite3 database instead of the session store, I don't think the performance on production will be much different between these two situation.

Answer 2

If you are using an AWS ElastiCache Memcached cluster, check the endpoint you used in your configuration $config['sess_save_path']. One option is to use the configuration endpoint (which contains .cfg.) or the individual node endpoint (which contains .0001., .0002. wait). If you use the configuration endpoint, make sure autodiscovery is enabled (requires additional installation on the server - ElastiCache Cluster Client for PHP). If not enabled, your nodes will not resolve correctly, causing issues like this.

It turns out that this is the case for me. I tried logging messages on sessions start, regenerate and destroy and with the file driver the regenerate happens, while with memcached it doesn't even call Any function except session_start(). After some investigation, I decided to recheck the host and stumbled upon this guide in AWS. It turns out that when the issue started, the second node was added to our Memcached cluster, but we had been using the configuration endpoint without setting this Autodiscover. I'm not sure how the setup works at all. So I changed $config['sess_save_path'] to the endpoint of one of the nodes and the problem went away. This solution should work until I install and setup the required modules, and as long as the node is unchanged.