Closed klimenttoshkov closed 4 years ago
The main idea of defining separate listener is that I want to process it in Queue and I want to avoid making Job and dispatching in from function that is defined in subscriber.
Can you send over the stack trace? I believe that's coming from the event dispatcher, but it's possible there may be some non-serializeable things (i.e. a closure) being appended to your model as well.
Please review attached file with the model, controller, listener and service provider. And the trace. all debug info.txt
I did some testing and isolated the problem to interface ShouldQueue. If it is used on a listener then those errors appear. It doesn't matter where the listener is defined and etc. Removing this interface fixes the error but what is important to me is to process using Queue.
It looks like the issue is in the serialization, so that would make sense if you remove the listener from queuing. Out of curiosity, in tinker or a test, try serializing a similar model ($model->jsonSerialize()
) and see if that throws the same error.
Seems fine to me:
$model=Modules\SmsNotification\Entities\Queue\Incoming::find(100); => Modules\SmsNotification\Entities\Queue\Incoming {#3354 id: 100, uuid: null, service_id: null, marking: null, created_at: null, updated_at: null, } $model->jsonSerialize(); => [ "id" => 100, "uuid" => null, "service_id" => null, "marking" => null, "created_at" => null, "updated_at" => null, ]
and then going further:
$model->workflow_apply('toAccepted'); Exception with message 'Serialization of 'Closure' is not allowed'
So basically it seems to me that if you try to apply workflow transition from Tinker the output would require serialisation and it will fail. The same applies for queued execution which leads to throwing the exception when trying to queue.
Ok, I found the issue. Deep in symfony, it looks like it's possible to have a guard that exposes an expression/closure. I'll work on a fix, and keep you posted.
Ok, just released 3.1.0 which should address that! Let me know if you run into anything else!
Thank you for quick and kind response
Still not able to queue event listeners:
`[2020-05-18 19:32:19] local.ERROR: Serialization of 'Closure' is not allowed {"exception":"[object] (Exception(code: 0): Serialization of 'Closure' is not allowed at /Users/sag/Documents/api/vendor/laravel/framework/src/Illuminate/Queue/Queue.php:147) [stacktrace]
"} `
I'll try and take another look at that soon. In the meantime, can you confirm that you're using v3.1.0 of this package? composer info | grep laravel-workflow
sag@Sags-MacBook-Pro-A1398 api % composer info | grep laravel-workflow zerodahero/laravel-workflow v3.1.0 Integerate Symfony Workflow component into Laravel.
— Kliment Toshkov mail@klimenttoshkov.com
On 19 May 2020, at 22:04, zerodahero notifications@github.com wrote:
I'll try and take another look at that soon. In the meantime, can you confirm that you're using v3.1.0 of this package? composer info | grep laravel-workflow
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zerodahero/laravel-workflow/issues/20#issuecomment-631021167, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIQGVPGCRVG2BEPWQDLE73RSLJ2FANCNFSM4M2UWJPQ.
It's been a busy week, but this is still on my radar. I should have time this weekend to take a closer look at it. Thanks for your patience.
On Wed, May 20, 2020, 12:09 klimenttoshkov notifications@github.com wrote:
sag@Sags-MacBook-Pro-A1398 api % composer info | grep laravel-workflow zerodahero/laravel-workflow v3.1.0 Integerate Symfony Workflow component into Laravel.
— Kliment Toshkov mail@klimenttoshkov.com
On 19 May 2020, at 22:04, zerodahero notifications@github.com wrote:
I'll try and take another look at that soon. In the meantime, can you confirm that you're using v3.1.0 of this package? composer info | grep laravel-workflow
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/zerodahero/laravel-workflow/issues/20#issuecomment-631021167>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AOIQGVPGCRVG2BEPWQDLE73RSLJ2FANCNFSM4M2UWJPQ .
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/zerodahero/laravel-workflow/issues/20#issuecomment-631606615, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRAFADIQ2CRWGFIY36CQTLRSQFFJANCNFSM4M2UWJPQ .
Ok, looks like not all the events dispatched were the ones in this package, so I'll update those and push a new patch for it, soon.
Here's the patch! I was able to recreate this locally with a similar setup that you posted, and this patch fixes that. https://github.com/zerodahero/laravel-workflow/releases/tag/v3.1.1
Let me know how it works for you!
Thank you, I need some time to think how to adjust the setup and test it. 3.1.1? :-)
Yep! v3.1.1
Previous is 1.3.2, are you sure not a mistake? — Kliment Toshkov mail@klimenttoshkov.com
On 03 Jun 2020, at 17:04, zerodahero notifications@github.com wrote:
Yep! v3.1.1
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zerodahero/laravel-workflow/issues/20#issuecomment-638219825, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIQGVIDFILEF67JXJ3VIATRUZJ75ANCNFSM4M2UWJPQ.
Previous version was 3.1.0
Hi, I'm happy to report that serializing is fine if event listener implements ShouldQueue interface then execution is queued properly.
I have the following in EventServiceProvider:
class EventServiceProvider extends ServiceProvider { protected $listen = [ 'workflow.smsNotificationIncoming.transition.toAccepted' => [IncomingListener::class], ];
When transition is applied, fails with: