Skip to content

fix(UniqueGenerator): prevent memory exhaustion when chaining unique()->optional()#1029

Open
teal-bauer wants to merge 1 commit intoFakerPHP:2.0from
teal-bauer:fix/unique-optional-memory-leak-2.0
Open

fix(UniqueGenerator): prevent memory exhaustion when chaining unique()->optional()#1029
teal-bauer wants to merge 1 commit intoFakerPHP:2.0from
teal-bauer:fix/unique-optional-memory-leak-2.0

Conversation

@teal-bauer
Copy link

Fixes memory exhaustion when using unique()->optional()->method() or unique()->valid()->method() chains by adding explicit optional() and valid() methods to UniqueGenerator.

This is the 2.0 branch counterpart to #1028.

When calling $faker->unique()->optional()->safeEmail(), the UniqueGenerator::__call() handler would call optional() on the underlying generator, returning a ChanceGenerator, then attempt to serialize() it for uniqueness tracking. The ChanceGenerator contains a reference to the entire Generator with all providers, causing massive serialized strings and exponential memory growth.

By adding explicit optional() and valid() methods to UniqueGenerator, ChanceGenerator now wraps UniqueGenerator (not the base Generator). When the final method is called, it delegates back to UniqueGenerator, which serializes only the final value (e.g., the email string), not generator objects.

Fixes #1027

…)->optional()

When calling unique()->optional()->method(), the __call handler would
serialize the returned ChanceGenerator object (which contains the entire
Generator with all providers) rather than the final value. This caused
exponential memory growth.

Adding explicit optional() and valid() methods ensures proper generator
chaining - ChanceGenerator now wraps UniqueGenerator, delegating back
for actual value generation while preserving uniqueness tracking.

Fixes FakerPHP#1027
@stale
Copy link

stale bot commented Feb 4, 2026

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 1 week if no further activity occurs. Thank you for your contributions.

@stale stale bot added the lifecycle/stale label Feb 4, 2026
@teal-bauer
Copy link
Author

Thank you but not thank you? These bots are so disrespectful.

@localheinz
Copy link
Member

I agree, I would remove the bot, but that would require a review from someone else because I cannot merge my own pull requests, @teal-bauer.

@teal-bauer
Copy link
Author

Hm, is there any way to revive this repo (if not project) then?

@stale stale bot removed the lifecycle/stale label Feb 4, 2026
@localheinz
Copy link
Member

The general question is whether it makes sense to continue on the path to 2.0, or instead keep this project maintained on the 1.x path.

As of the moment, I would favor the latter to keep the project usable.

@teal-bauer
Copy link
Author

I agree. If you look at my fork, I integrated a ton of my patches and tried to go down the 2.x route, but it doesn't seem beneficial enough given the limitations of the PHP engine, so I basically ripped out the 2.x stuff and instead made a hopefully solid 1.x that could become a 2.x just because of all the fixes etc...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

unique()->optional() causes massive memory usage due to serializing Generator

2 participants