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
Copy Markdown

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
Copy Markdown

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
Copy Markdown
Author

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

@localheinz
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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...

@stale
Copy link
Copy Markdown

stale bot commented Mar 8, 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 Mar 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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