Queued exports fail when using ->fromTable() due to closures being unserializable

iamaks1993 commented

2025-09-05 09:01:06 +00:00

(Migrated from github.com)

When trying to run an export with both ->queue() and ->fromTable(), the job fails with:

Serialization of 'Closure' is not allowed

This happens because the table definitions (formatStateUsing, visible, etc.) rely on closures, which cannot be serialized for the queue.

Steps to reproduce

ExcelExportBulkAction::make()
    ->exports([
        TaskReportExport::make()
            ->fromTable()
            ->queue(),
    ]);

Expected behavior
It should be possible to combine ->fromTable() with ->queue() so that large exports can be processed in the background while still respecting the table configuration (columns, filters, sorting).

Actual behavior

Laravel: 12.x
Filament: 4.x
filament-excel: 3.x.
PHP: 8.4

Question
Is there any planned support or recommended workaround for making ->fromTable()->queue() compatible (e.g., removing closures automatically, or allowing serialization of table state)?

When trying to run an export with both ->queue() and ->fromTable(), the job fails with: `Serialization of 'Closure' is not allowed` This happens because the table definitions (formatStateUsing, visible, etc.) rely on closures, which cannot be serialized for the queue. **Steps to reproduce** ``` ExcelExportBulkAction::make() ->exports([ TaskReportExport::make() ->fromTable() ->queue(), ]); ``` **Expected behavior** It should be possible to combine ->fromTable() with ->queue() so that large exports can be processed in the background while still respecting the table configuration (columns, filters, sorting). Actual behavior 1. Laravel: 12.x 2. Filament: 4.x 3. filament-excel: 3.x. 4. PHP: 8.4 **Question** Is there any planned support or recommended workaround for making ->fromTable()->queue() compatible (e.g., removing closures automatically, or allowing serialization of table state)?

👀 4

pxlrbt commented

2025-09-11 07:29:31 +00:00

(Migrated from github.com)

Thanks for reporting. Closures are either removed or serialized already, but when there is a new method that accepts a Closure, I need to track that down and remove it from serialization. I can have a look at it in the coming weeks.

KarlBoosterBaer commented

2025-10-02 09:22:27 +00:00

(Migrated from github.com)

Are there any updates on this issue?

pxlrbt commented

2025-10-02 09:37:55 +00:00

(Migrated from github.com)

No, sorry. Right now I am too busy with client projects. Hope to find some time the next wekks.

pwond commented

2025-11-04 10:22:50 +00:00

(Migrated from github.com)

There seems to be a partial workaround here that you can use ->useTableQuery with ->queue; however the formatStateUsing method on the Column instances seems to no longer inject $record so if you need a custom value, build it in the query to pass through that way. Interestingly $state is being injected ok.

I also have a report that only overrides the datasheet as needed to hand roll the sheet layout using fromArray in the export class. If I switch this to using queue I just get an empty sheet 🤔

There seems to be a partial workaround here that you can use ->useTableQuery with ->queue; however the formatStateUsing method on the Column instances seems to no longer inject $record so if you need a custom value, build it in the query to pass through that way. Interestingly $state is being injected ok. I also have a report that only overrides the datasheet as needed to hand roll the sheet layout using fromArray in the export class. If I switch this to using queue I just get an empty sheet 🤔

pwond commented

2025-11-04 10:30:12 +00:00

(Migrated from github.com)

for reference Im having this issue on PHP 8.3, Filament 3.3, Filament Excel 2.5

kayedspace commented

2025-11-18 14:33:14 +00:00

(Migrated from github.com)

Still facing the same issue

pxlrbt commented

2025-11-18 17:00:08 +00:00

(Migrated from github.com)

@kayedspace That's obvious, since there was no fix.