Which CI 4 hook point reliably intercepts requests during zero-downtime migration?

Question

When migrating a small CodeIgniter 4 application with zero-downtime requirements, the goal is to coordinate request routing, environment configuration, and service class availability across coexisting old and new code paths. CI 4's hook points and configurable base URLs provide mechanisms for phased rollout, yet their interaction during concurrent request handling introduces ambiguity. It remains uncertain whether a single hook can reliably intercept and redirect all request types without introducing routing gaps or session inconsistencies when base URL settings are switched at runtime. The precise goal is to identify a deterministic hook point that operates consistently across typical web server setups and CI 4's request lifecycle without requiring application restarts.

Can the `pre_system` hook reliably intercept all request types during a phased zero-downtime migration? Does CI 4's `routes.php` support dynamic base URL switching without full page reload? Which combination of controller hooks prevents double-processing when both old controllers and new service classes handle the same endpoint?

Tasadduq Burney · Answer

Direct answerNo. CodeIgniter 4 does not provide a single hook point that reliably intercepts every request type during a phased zero-downtime migration. Where present, the pre_system event fires early inside CodeIgniter::run(), but only after the web server has already routed or rewritten the request to public/index.php. Requests served by static asset handlers, reverse proxies, or custom error documents never enter CI 4, so no PHP hook can see them.Confirmed facts versus likely explanationConfirmed: app/Config/Routes.php and App::$baseURL are loaded once at bootstrap. Changing $baseURL at runtime does not re-route an in-flight request and is not shared across concurrent PHP-FPM workers. Event names and hook availability differ across CI 4.x releases, so pre_system should not be assumed to exist without checking the installed version.Likely explanation: The ambiguity comes from treating a bootstrap event as a request gateway. Hooks run inside CI 4’s lifecycle; they cannot intercept traffic that never reaches that lifecycle.Steps for this caseReplace hook-based interception with a CI 4 Filter. Create app/Filters/MigrationFilter.php with before() and after() methods.Register the filter in app/Config/Filters.php under $aliases and attach it to the route group covering the migrated endpoints.Gate old and new code paths with a shared feature flag—environment variable, config file, or database row—read inside the filter so only one path handles each URI.Keep routes.php static. Do not switch $baseURL at runtime; route old and new endpoints through disjoint route groups or versioned prefixes instead.Verify with a logging filter under concurrent requests: confirm only one code path handles each URI and that sessions remain consistent.Verification commandsgrep -n "pre_system" system/CodeIgniter.php
php -l app/Filters/MigrationFilter.phpMissing diagnostic detail: Do all requests pass through public/index.php, or are some served by static handlers or a reverse proxy before reaching CI 4? This determines whether any PHP-level interception is possible at all.

Which CI 4 hook point reliably intercepts requests during zero-downtime migration?

1 answer

Direct answer

Confirmed facts versus likely explanation

Steps for this case

Verification commands

Your perspective belongs here.

0 question comments