Filament action retries: client-side disabling versus server-side uniqueness constraints

Filament v3 form actions are Livewire server-side handlers that execute on every submission, so a user retrying a create or update action can trigger duplicate writes if the handler is not guarded. The framework does not provide a documented idempotency token or automatic deduplication for action invocations.

On the client side, disabling the action button during submission with Livewire's wire:loading.attr or Filament's disabled() method can reduce accidental double-clicks, though clicks arriving before the disabled attribute is applied may still pass through. On the server side, a unique database index rejects duplicate rows at the storage layer, but it does not surface a Filament-native retry message without custom validation or exception handling.

The unresolved decision is whether client-side disabling alone is sufficient for a low-concurrency admin panel, or whether server-side uniqueness constraints should be treated as mandatory regardless of the UI state. Version differences between Filament v2 and v3 in action lifecycle and Livewire integration add further uncertainty to which mitigation is reliable across upgrades.

Should a Filament v3 action rely on client-side disabling for retry protection, or must server-side uniqueness constraints be enforced independently of the UI? How should the trade-off be evaluated when the action performs an upsert rather than a simple insert? What verification steps confirm that repeated submissions do not duplicate writes under the chosen approach?