Testing Session Handler Migration: Redis-ext To Enhanced-redis

by Admin 63 views
Session Handler Migration: Testing migration from redis-ext to enhanced-redis-session-handler

Background

Currently, we're using redis-ext to store PHP sessions in Valkey within an Apache + mod_php environment. Our mission is to seamlessly migrate this session handler to uzulla/enhanced-redis-session-handler without losing any existing session data. This is a critical task, guys, and we need to ensure a smooth transition!

This issue is all about defining our verification plan and managing the tasks involved. We want to make sure everything is crystal clear and well-organized, so we can tackle this migration with confidence. Let's dive in and make this happen!

Verification Goals

Our main goal is to ensure a flawless transition. We need to verify the following:

  • That session data saved with redis-ext can be correctly read and written by enhanced-redis-session-handler. This is the core of the migration, ensuring our users don't experience any disruptions.
  • That reverse compatibility also exists (new handler -> old handler). This is crucial for rollback scenarios and gives us a safety net if anything unexpected occurs. We want to be prepared for any situation!
  • That the migration procedure is reliable, proven in a near-production Docker environment. We're not just testing in a vacuum; we're simulating the real world to catch any potential issues early on. This is about building confidence in our process.

To achieve these goals, we will set up a dedicated testing environment that closely mirrors our production setup. This will allow us to thoroughly evaluate the compatibility and reliability of the new session handler. Think of it as a dry run before the main event!

**Proposed Set of Configuration Files for the Verification Environment (Final Version)**

migration-validation/docker-compose.yml

version: '3.8'
services:
  php-apache:
    build: .
    ports:
      - "8080:80"
    volumes:
      - ./src:/var/www/html
  valkey:
    image: valkey/valkey:7.2
    ports:
      - "6379:6379"

migration-validation/Dockerfile

# Official Apache + mod_php image
FROM php:8.2-apache

# Install dependencies for redis-ext
RUN apt-get update && apt-get install -y \
    libssl-dev \
    && rm -rf /var/lib/apt/lists/*

# Install redis-ext
RUN pecl install redis && docker-php-ext-enable redis

# Install Composer
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

# Set working directory
WORKDIR /var/www/html

# Copy composer files and install dependencies
COPY src/composer.json .
RUN composer install --no-scripts --no-autoloader
RUN composer dump-autoload --optimize

migration-validation/src/composer.json

{
    "require": {
        "uzulla/enhanced-redis-session-handler": "dev-main"
    }
}

migration-validation/src/README.md (Execution Manual)

# Session Migration Validation

## 1. Objective
To verify the mutual compatibility of session data between `redis-ext` and `enhanced-redis-session-handler`. This is the heart of our validation process, making sure everything plays nicely together.

## 2. Execution Procedure

1.  **Environment Startup**
    ```sh
    docker-compose up --build -d
    ```
    This command brings our testing environment to life, spinning up the necessary containers.

2.  **Access the Test Page**
    Open `http://localhost:8080` in your browser. This is where the magic happens!

3.  **Compatibility Test**
    - If the current environment's `session.serialize_handler` is `php_serialize`:
      1. Click "Write with Old Handler (redis-ext) (php_serialize)". This simulates writing session data using the old handler and serializer.
      2. Click "Read with New Handler (php_serialize)" and verify that the data is displayed correctly. This confirms that the new handler can read data written by the old handler.

    - If the current environment's `session.serialize_handler` is `php`:
      1. Click "Write with Old Handler (redis-ext) (php)".
      2. Click "Read with New Handler (php)" and verify that the data is displayed correctly.

4.  **Reverse Direction Test (Optional)**
    Also, verify that you can write with the new handler and read with the old handler. This is our safety net, ensuring we can roll back if needed.

5.  **Environment Shutdown**
    ```sh
    docker-compose down
    ```
    This command gracefully shuts down our testing environment, freeing up resources.

migration-validation/src/index.php (Test Menu)

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>Session Migration Test</title>
    <style>body { font-family: sans-serif; }</style>
</head>
<body>
    <h1>Session Migration Test</h1>
    <p>Please follow the instructions in README.md to perform the test.</p>
    <p>Current Session ID: <?php echo htmlspecialchars(session_id() ?: '(none)'); ?></p>

    <h2>Write with Old Handler (redis-ext)</h2>
    <ul>
        <li><a href="test.php?handler=redis_ext&action=write&serializer=php_serialize" target="_blank">Write (php_serialize)</a></li>
        <li><a href="test.php?handler=redis_ext&action=write&serializer=php" target="_blank">Write (php)</a></li>
    </ul>

    <h2>Read with New Handler</h2>
    <ul>
        <li><a href="test.php?handler=new&action=read&serializer=php_serialize" target="_blank">Read (php_serialize)</a></li>
        <li><a href="test.php?handler=new&action=read&serializer=php" target="_blank">Read (php)</a></li>
    </ul>
    <hr>
    <p><a href="destroy.php">Destroy Session</a></p>
</body>
</html>

migration-validation/src/test.php (Test Execution Script)

<?php
require_once __DIR__ . '/vendor/autoload.php';

use Uzulla\EnhancedPHPSession\SessionHandlerFactory;
use Uzulla\EnhancedPHPSession\SessionConfig;

$valkey_host = 'valkey';
$valkey_port = 6379;
$prefix = 'PHPSESSID_';

$handler_type = $_GET['handler'] ?? 'redis_ext';
$action = $_GET['action'] ?? 'read';
$serializer = $_GET['serializer'] ?? 'php_serialize';

if ($handler_type === 'redis_ext') {
    echo "<h2>Handler: redis-ext</h2>";
    ini_set('session.save_handler', 'redis');
    ini_set('session.save_path', "tcp://{$valkey_host}:{$valkey_port}?prefix={$prefix}");
    ini_set('session.serialize_handler', $serializer);
} else {
    echo "<h2>Handler: enhanced-redis-session-handler</h2>";
    $config = new SessionConfig(
        "tcp://{$valkey_host}:{$valkey_port}",
        ['prefix' => $prefix, 'serializer' => $serializer]
    );
    $handler = SessionHandlerFactory::create($config);
    session_set_save_handler($handler, true);
}

session_name("PHPSESSID");
session_start();

echo "<p>Action: <strong>{$action}</strong>, Serializer: <strong>{$serializer}</strong></p>";

if ($action === 'write') {
    $_SESSION['time'] = time();
    $_SESSION['handler'] = $handler_type;
    $_SESSION['serializer'] = $serializer;
    $_SESSION['rand'] = bin2hex(random_bytes(4));
    echo "<h3>Session Data Written:</h3>";
} else {
    echo "<h3>Session Data Read:</h3>";
}

echo "<pre>";
print_r($_SESSION);
echo "</pre>";

session_write_close();
?>

migration-validation/src/destroy.php

<?php
session_start();
session_destroy();
echo "Session destroyed. <a href='index.php'>Back to menu</a>";
?>

TODO

We have a clear plan, guys! Now, let's break it down into actionable tasks. We'll use pull requests (PRs) to manage the code changes and ensure a smooth review process.

  • [ ] 1. Building the Verification Environment (Requires PRs)

    • [ ] Task 1a: Docker Environment Setup (PR-1)
      • Create the migration-validation directory. This is our project's home.
      • Add Dockerfile and docker-compose.yml to build a basic environment with Apache+PHP and Valkey running. These files define our testing environment.
      • Place composer.json. This file manages our PHP dependencies.
    • [ ] Task 1b: Creating the Test Procedure Manual (PR-2)
      • Create migration-validation/src/README.md and describe the purpose of the test and manual execution procedures. This is our guide for running the tests.
    • [ ] Task 1c: Implementing the Test Script (PR-3)
      • Create index.php, test.php, and destroy.php to allow session writing/reading from the browser. These scripts will be our testing tools.

  • [ ] 2. Test Execution and Result Reporting (No PR Required)

    • [ ] Investigate the setting value (php or php_serialize) of session.serialize_handler in the current environment. This is crucial for accurate testing.
    • [ ] After all the above pull requests are merged, execute the test according to the procedure in README.md. Let's put our environment to the test!
    • [ ] Post the test results (success/failure, screenshots, etc.) and the conclusion on whether a safe migration is possible as a comment to this Issue. We need to document our findings clearly.

This is a comprehensive plan to ensure a safe and reliable migration. Let's work together, guys, and make it happen!