Bulk action retries may duplicate writes when a record fails

Answer

Filament bulk actions do not provide a retries() method, so Laravel’s queue retry will re‑execute the entire job when any record throws an exception. To avoid duplicate writes you must make the per‑record work idempotent or split the work into separate jobs.

Confirmed facts

• Laravel queue retry re‑runs the whole job class unless the job defines its own retries() method or catches exceptions internally.
• Filament’s bulk action closure runs inside a single queued job that loops over each selected record.
• If an exception is thrown for one record, the job fails and a retry will process all records again.

Recommended steps for this case

1. Inside the bulk‑action closure, before applying changes, check an idempotency marker that is unique to the record and the action (e.g., a flag column, a version stamp, or a cache key).
2. If the marker indicates the action has already been applied, skip the processing and continue to the next record.
3. Make sure this check occurs outside any database transaction that rolls back on failure, otherwise a rolled‑back transaction can hide the fact that the record was already processed.
4. Optionally, use an upsert (updateOrCreate) keyed by the record ID and action type so repeated attempts are safe.
5. If you prefer to keep the current job structure, add a try/catch around the per‑record logic, log the failed record, and let the job finish successfully; then you can rely on Laravel’s retry only for truly fatal errors.

Test scenario to verify no duplicate writes

1. Create a test bulk action that selects three records (A, B, C).
2. Make the processing for record B throw an exception (e.g., throw new \Exception('fail')).
3. Allow the job to fail, then trigger a Laravel queue retry (e.g., php artisan queue:retry ).
4. After the retry finishes, assert that a counter column (or any side‑effect) has been incremented exactly once for records A and C, and zero times for B (or that B remains unchanged).
5. When using an idempotency key, also assert that a second retry does not increase the counter for A or C again.

Missing diagnostic detail

Does your bulk‑action closure wrap the per‑record work in a database transaction? If yes, the idempotency check must be placed outside that transaction; otherwise a rolled‑back transaction can hide the fact that a record was already processed and cause duplicate writes on retry.