- What does mpyw/laravel-retry-on-duplicate-key do?
- It is a small Laravel package that retries non-atomic Eloquent write operations when the database raises a duplicate key error. It is intended for calls such as firstOrCreate, updateOrCreate, or insert that can race under concurrent writes and violate a unique constraint. It wraps those operations in a retryable transaction rather than replacing them with a database-native atomic upsert.
- How do I install mpyw/laravel-retry-on-duplicate-key in Laravel?
- Install it with Composer using composer require mpyw/laravel-retry-on-duplicate-key and follow the package README for any service provider or configuration steps. Because the repository is archived and last released in March 2023, verify its Composer constraints and Laravel auto-discovery behavior before adding it to an existing app. If constraints fail, the MIT-licensed retry logic is small enough to vendor into application code.
- Which Laravel and PHP versions does laravel-retry-on-duplicate-key support?
- The package targets Laravel applications that use Eloquent and Query Builder, but the exact supported Laravel and PHP versions should be checked against its composer.json and release history. Its last release was March 2023, so do not assume compatibility with Laravel 11 or 12 without a compatibility spike. Test the package against your current PHP, Laravel, and database matrix before adoption.
- How many times does it retry a duplicate key error and is there backoff?
- The package provides a retryable transaction wrapper, but the README and source should be checked for the exact retry-count and backoff configuration available in your version. For production use, prefer a bounded retry limit with backoff or jitter rather than unbounded retries, because duplicate-key storms can amplify database load. Add metrics around retry counts and final failures so the behavior is observable.
- Does it work with MySQL, PostgreSQL, and SQLite duplicate key errors?
- It is designed to catch duplicate key errors from Laravel's database layer, but support depends on how each driver reports unique constraint violations and how the package classifies exception codes. Validate it explicitly on MySQL, PostgreSQL, and SQLite if those are in your stack, and confirm that it targets the intended unique constraint rather than unrelated duplicate-key errors. Do not assume identical behavior across drivers without tests.
- Does the package retry the whole transaction or only the failed insert?
- The package is described as wrapping non-atomic upsert calls in a retryable transaction, so the retry unit is the wrapped operation rather than a separate manual catch around one statement. Confirm in the source whether your version retries the entire callback or only the failed database call, because that affects side effects and transaction state. This distinction matters when the operation includes model events, auditing, or queued jobs.
- Can I use it inside an existing database transaction?
- Using it inside an existing transaction depends on the package's transaction nesting and rollback behavior, which should be verified before production use. On some databases a duplicate-key error can abort the current transaction, so retrying inside an outer transaction may not behave as expected. Keep the retry boundary explicit and test nested-transaction scenarios if your application already manages transactions.
- How should I test and monitor duplicate-key retries in production?
- Retries can re-run Eloquent model events, observers, auditing hooks, and dispatched jobs, so those side effects must be idempotent or isolated from the retried callback. Test with concurrent writes that deliberately trigger duplicate-key failures, and instrument retry counts, final failures, and latency. Deploy behind one low-risk write path first rather than applying the wrapper broadly.
- Is mpyw/laravel-retry-on-duplicate-key still maintained?
- The repository is archived, last released in March 2023, and has very low ecosystem validation, so active upstream maintenance should not be expected. The adopting team effectively owns compatibility, security review, bug fixes, and Laravel upgrade testing. For long-term use, plan to vendor or reimplement the small MIT-licensed retry logic in application-owned code.
- What are alternatives to retrying updateOrCreate duplicate key errors?
- Prefer database-native atomic operations such as Laravel's upsert, insertOrIgnore, or database-specific ON CONFLICT handling when they fit your use case. If you need retries, compare keeping the package, vendoring its retry pattern, or building a small internal helper with explicit limits and metrics. The package is best treated as a tactical workaround for observed duplicate-key races, not a replacement for fixing atomicity or schema issues.