faker seed is not applied after kernel shutdown

[verfriemelt-dot-org]

hi,

image a symfony kernel testcase like this:

class FakerTest extends ApplicationWebTestCase {
    public function test(): void {
//        $this->client->request('get','/');
        static::assertSame('dolore', faker()->word());
    }
    public function test2(): void {
        static::assertSame('distinctio', faker()->word());
    }

    public function test3(): void {
        // 924691
        static::assertSame('dolore', faker()->word());
    }
    public function test4(): void {
        // 924691
        static::assertSame('distinctio', faker()->word());
    }
}

(the kerneltestcase has use Factories;, nothing to fancy in the shutdown, kernel gets rebootet with every test)

running this via

$ FOUNDRY_FAKER_SEED=924691 phpunit --testsuite Application --filter Faker
[...]
..FF                                                                4 / 4 (100%)

Faker seed: 924691

Time: 00:00.071, Memory: 28.00 MB

There were 2 failures:

1) FakerTest::test3
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'dolore'
+'odit'

FakerTest.php:17

2) FakerTest::test4
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'distinctio'
+'vitae'

i get what i expect, the "errors" stay the same, because the seed is actually used. if i now run the request $this->client->request('get','/'); , those values will not stay the same anymore,

i would expect to be stable, but with every run of the tests there will be different outcomes 🤔

Current configuration for extension with alias "zenstruck_foundry"
==================================================================

zenstruck_foundry:
    persistence:
        flush_once: true
    enable_auto_refresh_with_lazy_objects: true
    auto_refresh_proxies: null
    faker:
        locale: null
        seed: null
        service: null
    instantiator:
        use_constructor: true
        allow_extra_attributes: false
        always_force_properties: false
        service: null
    global_state: {  }
    orm:
        auto_persist: true
        reset:
            connections:
                - default
            entity_managers:
                - default
            mode: !php/enum Zenstruck\Foundry\ORM\ResetDatabase\ResetDatabaseMode::SCHEMA
            migrations:
                configurations: {  }
    mongo:
        auto_persist: true
        reset:
            document_managers:
                - default
    make_factory:
        default_namespace: Factory
        add_hints: true
    make_story:
        default_namespace: Story

this is symfony8, php8.5, latest foundry version

any suggestions where to look for to fix this?

[verfriemelt-dot-org]

so i investigated a bit more, and it seems to be related to garbage collection. the legacy project i am working on is fairly big and triggers garbage collection during startup, which reaps the generator thus triggering Generator::__destruct() and resetting the seed.

running the test with php -d zend.enable_gc=0 prevents the issue

[verfriemelt-dot-org]

after tinkering a bit, keeping the reference alive via patching the faker factory here

    public static function create($locale = self::DEFAULT_LOCALE)
    {
-       $generator = new Generator();
+       static $generator = new Generator();

        foreach (static::$defaultProviders as $provider) {
            $providerClassName = self::getProviderClassname($provider, $locale);
            $generator->addProvider(new $providerClassName($generator));
        }

        return $generator;
    }

the whole issue goes away 🤔
not sure how to resolv this properly though

[nikophil]

Hi @verfriemelt-dot-org

hmmm I'm wondering if when you call $this->request(), Foundry gets booted again and we re-init the seed 🤔

could you check how many times we pass in this line?

Could you also try branch 2.x-dev, as we've recently changed something in how Foundry is booted

If 2.x-dev does not work, could you create a small reproducer please?

[verfriemelt-dot-org]

i'll check this out as soon as i find time and come back to you. the reproducer could be hard, because its depending on the garbage collection cycle, but in theory it should be enough to manually trigger this. i will see what i can manage.

[verfriemelt-dot-org]

could you check how many times we pass in this line?

in total 6 times for all 4 tests, both with and without gc enabled.

when switching to 2.x-dev at f18a179 its the very same result.