faker data collisions breaking uniqueness constraints: how to fix

TL;DR

Faker is random, and random values collide. For any column with a uniqueness constraint, append something guaranteed unique: a sequence counter, a timestamp, or a UUID fragment. Seed faker too, so failures are reproducible. The rule is simple: faker for realistic shape, your own suffix for uniqueness.

The query

faker data collisions breaking uniqueness constraints: how to fix

Use this when

• Tests fail intermittently with duplicate key or unique constraint violations
• Factories generate emails, usernames, or order numbers with faker alone
• Parallel tests insert into the same tables

Not for

• Generating production seed data (different requirements)
• Anonymizing real user data
• Fixing collisions in non-unique columns (those do not break anything)

Steps

1. Find the colliding column. The database error names the constraint; map it back to the factory field that feeds it.

Expected output: the exact column and factory field identified from one failing run.

1. Add a uniqueness suffix in the factory. Append a per-test counter, a timestamp with enough precision, or a short UUID to the faker value.

Expected output: the factory updated so the unique field can never repeat within a run.

1. Seed faker for reproducibility. Set a fixed seed in test setup so a failing run can be replayed exactly.

Expected output: the same seed producing the same data on rerun, verified by replaying a failure.

1. Make parallel runs safe. Include the worker id or process id in the suffix so two parallel workers cannot generate the same value.

Expected output: a suffix containing the worker identifier, with parallel runs green.

1. Run the suite ten times. Collisions are probabilistic, so one green run proves nothing.

Expected output: ten consecutive green runs with no duplicate-key errors.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ebUoxQIvbLZKq-KMhaPntQ