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

Direct Answer

Client-side disabling alone is not sufficient for retry protection in Filament v3. Server-side uniqueness constraints must be enforced independently of the UI for both create and upsert actions. Client-side measures improve user experience but cannot guarantee idempotency under network retries, concurrent sessions, or requests already in flight.

Why Client-Side Disabling Fails as a Safety Control

• Confirmed: Filament v3 form actions are Livewire server-side handlers executed on every submission. The framework provides no documented idempotency token or automatic deduplication.
• Confirmed: wire:loading.attr="disabled" or Filament's disabled() method only applies after the first request leaves the browser. Clicks arriving before the attribute is applied, browser back-button resubmits, network-layer retries, and concurrent tabs all bypass client-side disabling.
• Likely explanation: In low-concurrency admin panels with fast latency, client disabling appears to work because the race window is small. This is a UX improvement, not a correctness guarantee.

Server-Side Requirements (Mandatory)

1. Unique database index on the business key (e.g., email, slug, composite natural key).
2. Model validation that checks uniqueness before the write attempt and returns a Filament-native validation message.
3. Exception handling in the action handler to catch constraint violations from concurrent requests that pass validation but race at the database layer, converting them to user-facing notifications.

Upsert vs. Insert: How the Trade-Off Shifts

For a simple insert, the failure mode is duplicate rows. For an upsert (e.g., updateOrCreate on a natural key), the failure mode is unintended overwrites — a retry may silently replace data written by a concurrent request. The server-side constraint on the natural key remains mandatory; you must also decide whether the upsert logic should be idempotent (re-applying the same input produces the same state) or whether a retry should be rejected as a conflict.

Verification Steps

1. Add a unique index on the business key in a migration and run php artisan migrate.
2. In the action handler, add a validation rule: Rule::unique('table', 'column')->ignore($this->record?->id).
3. Wrap the write in a try/catch for Illuminate\Database\QueryException with error code 23000 (integrity constraint) and call Notification::make()->danger()->title('Duplicate entry')->send().
4. Simulate rapid double-submit: open the form in two tabs, submit simultaneously, or use browser dev-tools network throttling + repeated clicks. Confirm only one row exists and the second attempt shows a validation/notification message.
5. Check database row count and application logs after the test.

One Diagnostic Detail That Could Change the Recommendation

Does the action perform any non-idempotent side effects (email sends, webhook calls, external API mutations) before the database write? If yes, you need an application-level idempotency key (stored in a separate table with a unique constraint) in addition to the database uniqueness constraint, because the DB index only protects the write, not the side effect.