Last updated on August 21st, 2026 at 01:04 pm
The main lesson: a table row can be visible in Filament while a later modal callback still receives no record. This often happens because the action schema or searchable field is evaluated in a separate request. A composite database key makes record restoration even harder.
What I learned
I was troubleshooting a table action whose searchable Select needed the current row. The database query worked on its own, but the callback received null instead of the expected model.
The important distinction is that opening an action and searching inside its modal are not always one continuous request. Filament may cache or rebuild the action schema, then handle Select searches through another Livewire request. A callback that assumes the row model is always available can therefore fail.
Why composite keys add difficulty
Laravel Eloquent expects one primary-key column by default. A table identified by two columns, such as parent_id plus slug, does not fit that convention.
The database can enforce that composite key correctly, but Eloquent and Filament still need a stable value to route, serialize, and restore the record between requests. Without that bridge, authorization, edit, search, or delete actions may receive a missing record.
A reliable troubleshooting process
- Test the query separately. Confirm the expected rows exist before changing the UI.
- Inspect the callback lifecycle. Check whether the failure occurs while opening the modal or during an asynchronous search request.
- Remove unsafe assumptions. Do not type-hint a non-null record in callbacks that Filament may evaluate without one.
- Use a stable record identity. Prefer a normal single-column primary key when the schema can change. Otherwise, encode and restore the composite identity deliberately.
- Choose the simpler UI flow. If a modal cannot preserve context reliably, use a standard edit page where the record remains mounted for the form lifecycle.
Cause and fix
Cause: the action schema is evaluated while Filament is caching or rebuilding it.
Fix: make schema construction independent of a row, or build the schema only after a record is reliably mounted.
Cause: a searchable Select performs a separate Livewire request.
Fix: pass a stable scalar value into the field, instead of asking the field callback to rediscover the model.
Cause: the model uses a composite primary key that Eloquent cannot declare natively.
Fix: add a conventional key when practical. If that is not possible, use a stable route key and make update and delete queries match every key column.
Common mistakes
- Assuming a successful SQL query proves the modal has the correct row context.
- Adding more Livewire lookups when the action lifecycle is the actual problem.
- Using a built-in edit action without a working record route.
- Updating or deleting by only one column of a composite key.
Conclusion
When a Filament action receives a null record, first check the action lifecycle and record identity—not the database query. My concrete next action is to prefer a standard edit page for composite-key records unless a modal can be verified with a real Livewire interaction test.