Default value persistence in Filament Repeater after migration rollback

Answer

Filament does not automatically re-execute the default closure after a migration rollback. The closure runs only once during the component's initial mount. If a rollback drops the underlying table, the form will render without rows because the state created by the initial closure is gone and the trigger for a new one has already passed.

Behavioral Analysis

Confirmed Facts

• Closure Lifecycle: The default closure is designed for initial state setup, not for maintaining data integrity across database schema changes.
• Migration Impact: Laravel's migrate:rollback removes the database structure, but since the Filament component is already initialized in the application lifecycle, it does not "reset" to trigger the default closure again.
• Lazy Rendering: When the lazy option is enabled, the repeater's content is deferred. This does not fix the missing data; it simply masks the absence of default rows until the user interacts with the field.

Proposed Resolution

To ensure default rows persist or are recreated after a rollback, you must implement manual reseeding logic. The most reliable approach is overriding the mount method of the Livewire component or using a lifecycle hook to verify data existence.

1. Implement a Presence Check: Use the mount method to check for the existence of the table or the required default records.
2. Execute Idempotent Seeding: Use firstOrCreate or a similar method to avoid duplicating rows if the migration is re-run.

public function mount()
{
    if (!Schema::hasTable('repeater_table_name')) {
        // Handle missing table scenario
        return;
    }

    if (YourModel::count() === 0) {
        YourModel::create(['column' => 'default_value']);
    }
}

Verification Steps

To verify this behavior in a development environment:

• Define a Repeater with a default() closure.
• Run php artisan migrate, then php artisan migrate:rollback.
• Refresh the page; observe that the repeater is empty.
• Apply the mount logic above and refresh again to confirm the row is restored.

Missing Diagnostic Detail

Does the rollback drop the entire table, or does it only remove specific columns? If the table remains but is simply emptied, a simple exists() check is sufficient; if the table is dropped, the Schema::hasTable check is required to prevent SQL errors during the mount process.