[samdark]

Closes #78.

Changes

• src/Codeception/Lib/Connector/Yii2.php:
  • In startApp(), the module logger is installed before Yii::createObject() builds the application, and restored afterwards if the application's own bootstrap replaced the global logger during the build.
  • A register_shutdown_function() in the yii\log namespace is installed once per process. While an application is starting — and until it is reset — the shutdown registrations made by yii\log\Logger::init() (the flush closure and the final flush(true)) are stored on the connector with their arguments instead of being registered with PHP. resetApplication() runs the stored registrations until the queue is empty, before tearing the application down.

Why

While createObject() builds the application, the build itself already calls Yii::getLogger() (log dispatcher construction and debug bootstrap). When no logger is installed yet, a plain yii\log\Logger is created at that point. Its init() calls register_shutdown_function() with a closure bound to itself, and PHP keeps every shutdown function until the process ends — so each test leaves behind its logger together with its dispatcher, log targets, logged messages and the application they hold. The retained set grows with every test, and a large suite eventually exhausts memory_limit.

Installing the module logger before the build only covers the default logging setup: an application can still install its own plain logger (a bootstrap callback, an explicit Yii::setLogger()), and that logger's shutdown registrations would still retain it — together with its dispatcher, targets and application state — until process exit. So while an application is starting, the module intercepts shutdown registrations made in the yii\log namespace (Yii does not import the function, so the unqualified calls in Logger::init() resolve there) and stores the callables with their arguments instead of registering them. resetApplication() then invokes them until the queue is empty — invoking the stored outer closure re-registers the nested final flush(true), which is why the drain loops. This also delivers messages that were logged through an application-bootstrapped logger during a test straight to its targets, instead of only at process exit.

A bootstrap callback may also replace the global logger itself; restoring the module logger after the build keeps that replacement confined to the bootstrap phase, so the global logger is the module logger both during and after the build and the yii-log failure report keeps the diagnostic messages of the test in which the failure happened. The module logger itself is never intercepted: its init() override performs no registration.

Related: #144 is a separate per-test leak with a different cause; this does not address it.

[SamMousa]

If the application bootstraps its own logger then we still get the issue with register shutdown function leaking memory

[samdark]

Any idea on how to fix it?

[samdark]

A plain Yii logger registers shutdown callbacks when constructed. Installing the module logger earlier prevents that implicit construction on the default path, but an explicitly configured or bootstrapped plain logger can still retain the application through its dispatcher and targets.

For an exclusively owned logger, application-controlled teardown can flush pending messages and detach the dispatcher to release that graph; the logger itself remains registered until process exit. The module cannot safely apply that cleanup to every logger: a shared logger may still need its dispatcher, and detaching it loses later messages. A logger that avoids shutdown registration is another option, provided its flush/export behavior is handled explicitly. I've narrowed the PR description to make this boundary clear.

[SamMousa]

One way to fix it would be to intercept the call to register_shutdown_function.
It'd actually allow for cleaner testing that includes the flush.
Since Yii does not use \register_shutdown_function nor does it import the function via use \register_shutdown_function normal namespace rules apply.

If we register a function in the namespace:

namespace yii\log {
    function register_shutdown_function($cb) {
    // noop, or even better, register this on some static client stuff so it can be called after a test, or after a request
    
    }
}

so each test leaves behind its logger together with its dispatcher, log targets, logged messages and the application they hold.

Actually, dispatcher is only initialized after app construction (since it's an app component).
The idea is (i think, it's not originally my code) that we can have logs during this phase even when no dispatcher is set up yet.

I think if you paste this inside the client this could work:

public static function appStarting(): bool {
        return self::$appStarting;
    }

    public static function registerShutdown(callable $callable, mixed ...$args) 
    {
        // For now we NOOP it. Later we could store these and call them after a test / after a request
        codecept_debug('Shutdown function registered, we\'re ignoring it');
    }


    private static bool $appStarting = false;

    public function startApp(?\yii\log\Logger $logger = null): void
    {
        if (!function_exists('\yii\log\register_shutdown_function')) {
            /**
             * We cannot guarantee this code does not get executed in a prod environment.
             * Therefore we register function that has a guard
             */
            eval(<<<PHP
                namespace yii\log {
                    function register_shutdown_function(callable $callable, mixed ...$args) {
                        if (Codeception\Lib\Connector\Yii2::appStarting()) {
                            Codeception\Lib\Connector\Yii2::registerShutdown($callable, ...$args);
                        }
                        return \register_shutdown_function($callable, ...$args);
                    }
                }
            PHP);
        }
        ...

[samdark]

I tried this here, measuring it in isolation: 24 application build/reset cycles on a vendored yii2, with an app whose bootstrap installs its own plain yii\log\Logger (the residual case from the comment above), and counting what is still reachable after each reset.

As written, the interceptor forwards to the real register_shutdown_function in all cases, so it does not change retention: after 24 cycles one app logger is still retained per cycle, and its pending messages are flushed only at process exit (the current head of this PR shows the same behavior; it only fixes the default logging setup).

Storing instead of forwarding fixes it: while an application is starting, the registrations are stored with their arguments (Logger::init() registers both the flush closure and the final [$this, 'flush'], true — that argument gates target export and must survive the store/invoke round-trip), and resetApplication() runs them before tearing the application down, looping until the queue is empty because the stored outer closure re-registers the nested one. Result: no loggers retained across tests, and messages logged through the app's own logger during the test reach its targets instead of only at process exit. The module logger itself is never touched (its init() performs no registration).

Two implementation notes from the experiment: inside the eval'd namespace yii\log block the connector's statics must be referenced fully qualified (unqualified names resolve into yii\log), and the install guard is function_exists('\yii\log\register_shutdown_function').

Applied to the branch: bfb1f63.

[Copilot]

🟡 Changes recommended

Shutdown-callback interception can suppress shared loggers’ process-exit flushes and leave callbacks or application state retained after reset.

4 open issues

• Drain finite callback queues instead of retaining leftovers · New
• Close the session before draining callbacks and disabling interception · New
• Install shutdown interception before any logger initialization · New
• Preserve shutdown callbacks for externally shared loggers · New

What changed in this PR

This PR addresses logger-related memory retention in the Yii2 connector and preserves failure diagnostics when application bootstrap replaces the global logger.

Changes:

• Installs the module logger before application construction and restores it afterward.
• Adds interception and reset-time replay of Yii logger shutdown callbacks.
• Adds regression suites for logger installation timing and failure-report logging.

File	Description
tests/​cases/​leak/​functional/​LeakCest.php	Checks logger installation before application construction.
tests/​cases/​leak/​functional.suite.yml	Enables modules for the leak regression suite.
tests/​cases/​leak/​config.php	Configures the logger-observing application.
tests/​cases/​leak/​codeception.yml	Configures the leak test project.
tests/​cases/​leak/​app/​App.php	Records the logger class at constructor entry.
tests/​cases/​bootstrap-logger/​functional/​BootstrapLoggerCest.php	Checks failure diagnostics after bootstrap replaces the logger.
tests/​cases/​bootstrap-logger/​functional.suite.yml	Configures bootstrap-logger testing modules and steps.
tests/​cases/​bootstrap-logger/​config.php	Installs a custom logger during bootstrap.
tests/​cases/​bootstrap-logger/​codeception.yml	Configures the bootstrap-logger test project.
tests/​cases/​bootstrap-logger/​app/​CustomLogger.php	Provides a replacement logger without shutdown registration.
tests/​cases/​bootstrap-logger/​app/​App.php	Defines the bootstrap-logger application fixture.
src/​Codeception/​Lib/​Connector/​Yii2.php	Changes logger installation timing and shutdown-callback handling.

_{Review effort: Balanced}

[samdark]

Small follow-up on the branch: c3d61e7.

Review of bfb1f63 caught one PHPStan finding: the splatted variadic args in registerShutdown() are typed array<int|string, mixed>, which did not match the declared list<mixed> of the deferred-shutdowns property. A variadic array is always int-keyed at runtime, so the fix is a no-op normalization to array_values($args) — no behavior change; the suite results and the retention measurements above still hold on the new head.

[samdark]

Follow-up on the automated review — all four points checked in isolation, three led to changes in 9facd8c, one is a documented trade-off:

1. Drain cap (L201) — fixed. Confirmed the dynamics: the queue drains FIFO, and a plain logger contributes exactly two invocations per drain (the stored outer closure first, then the nested final flush(true) it re-registers when invoked), so 51 loggers need 102 invocations and the old cap of 100 stops two entries short (reproduced: 49 flushed, 2 left). The cap is now sized at four times the queue's own size, which fully covers any finite logger queue; it still bounds pathological re-registration, and any leftover beyond that stays in the queue until the next drain — never in PHP's real shutdown registry. Re-verified: 51 logger pairs now drain to 51 flushed / 0 left.

2. closeSession() ordering (L242) — fixed as suggested. Confirmed the path: closeSession() calls getApplication(), which starts an application when Yii::$app is null. With the drain and the flag-clear happening first, that late build re-enabled interception and left its logger registrations pending — reproduced in isolation: after such a reset the flag was true, one callback was pending and that app's final flush had not run. closeSession() now runs first, while the flag is still on, so that build's registrations are captured and drained in the same reset; the drain still happens before Yii::$app = null, so targets that use the app during export are unaffected.

3. Fallback caching (L396) — not a PHP issue; the window is now narrowed anyway. PHP resolves unqualified function calls at runtime with a per-call namespace fallback — it does not cache a decision to call the global function. Verified in isolation, including under the opcode cache: a class with an unqualified register_shutdown_function call was compiled (and required, served from the opcode cache) before the namespaced function existed; defining the function afterwards still intercepted both calls (hook_fired=2, no real shutdown registration at exit). So existing call sites are redirected. That said, the one real gap was the config file: it is included before the hook was installed, and a plain logger constructed there would have registered a real shutdown callback. The hook install and the flag now happen before include $this->configFile, closing that window.

4. Shared loggers (L401) — documented trade-off, no change. The deferral is the leak fix, and the flush is not dropped: buffered messages are exported to the targets during the reset, which is strictly earlier than process exit. The accepted cost is that a logger instance kept in use after its application's reset loses its process-exit auto-flush for any further messages — that logger would have to call flush() itself. That scenario sits outside this module's lifecycle: each test's application (and with it its loggers) is discarded on reset and the global logger is cleared, so an application-created logger is not shared across tests. Making the interception opt-in would require the application's own bootstrap code — the exact code path this is fixing — to know about it.

All re-verified at 9facd8c: phpstan report identical to the PR base (0 errors in the changed file), ECS clean, the six runnable local suites green (17 tests), and the 24-cycle real-module retention check unchanged (retained flat at 1, all 24 marker lines flushed in-run, module logger intact).