Bulk action retries may duplicate writes when a record fails

Goal: guarantee that a retry of a Filament table bulk action job does not re‑process records that already succeeded, preventing duplicate writes when individual record failures occur.

Constraint: the bulk action is dispatched as a single queued job that loops through each selected record inside its closure; Filament provides no retries() method, so Laravel's queue retry will re‑execute the entire job on any exception unless the developer manually partitions the work or adds idempotency checks.

Uncertainty: whether Filament should expose a retries() configuration that integrates with Laravel's retry attempts, or if developers must rely on external idempotency keys or per‑record job splitting to achieve safe retries.

Specific questions: Should Filament add a retries() method on bulk actions to coordinate with Laravel's queue retry settings? How can developers implement idempotency keys inside the bulk action closure without affecting the user experience? What test scenario confirms that retrying a failed bulk action does not duplicate writes for previously successful records?