Sometimes broadcast not coming through

[Treggats]

I have an Laravel app with an React frontend, Redis as queue driver and laravel-websockets
It runs on a Forge server with php opcache enabled and I have daemons for websockets:serve and Horizon to manage my queue's.

Sometimes after a deploy or when I manually change a php file on the server and restart php/queue's. The broadcasts are not coming through anymore.

The bandaid I have for this at the moment is to switch to the sync queue connection for a while and switch back to redis. After this the broadcasts are coming through again.

I've been asking around about this behaviour, but haven't found anyone who has experienced something similar.

Any help, tips or otherwise are most welcome!

[MWL91]

I have a question for you, because i dealing with similar problem. Did the pushes not comming in your case always, or from time to time?

After last deploys and installing dependency like here: #216 (installing old react/dns) i have similar problems.

Did you solved yours? Did you use the old dependency of react/dns?

[Treggats]

I don't have the issues as described there, I can start the websocket server without problems. The broadcast just sometimes doesn't get through Op ma 22 jul. 2019 16:08 schreef Exulto Webdevelopment Poland < notifications@github.com>:

…

I have a question for you, because i dealing with similar problem. Did the pushes not comming in your case always, or from time to time? After last deploys and installing dependency like here: #216 <#216> (installing old react/dns) i have similar problems. Did you solved yours? Did you use the old dependency of react/dns? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#219?email_source=notifications&email_token=AAAGXQKBJ7RRPW23HV5GDIDQAW5PDA5CNFSM4ICRISQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2QBFRI#issuecomment-513807045>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAGXQJRAA7AK3PPECA4V63QAW5PDANCNFSM4ICRISQQ> .

[MWL91]

So i have the same issue here, have you sth in logs?
In mines there are no errors or such a things.

Can anyone solved it? I don't even know how to start to solve this problem...

[Treggats]

No, I don't. Nothing in the logs or something to go on Op ma 22 jul. 2019 16:35 schreef Exulto Webdevelopment Poland < notifications@github.com>:

…

So i have the same issue here, have you sth in logs? In mines there are no errors or such a things. Can anyone solved it? I don't even know how to start to solve this problem... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#219?email_source=notifications&email_token=AAAGXQKJMWTW52C6QDUF3KTQAXARHA5CNFSM4ICRISQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2QDXVI#issuecomment-513817557>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAGXQMQL43QQFBNTIECKLTQAXARHANCNFSM4ICRISQQ> .

[francislavoie]

To clarify - this is how broadcasting will work in your case:

• Laravel app (PHP-FPM or whatever) will broadcast an event
• The broadcasted event is pushed to the queue on Redis as a serialized class
• A horizon worker pulls down the broadcasted event from Redis (with lpop I think), unserializes it, and handles it as a job
• The worker uses the configured broadcast to publish the message on the event (i.e. PusherBroadcaster)
• laravel-websockets receives the broadcasted message over HTTP from the worker
• TriggerEventController in laravel-websockets handles the message and sends it out to connected clients on the targetted channel.

So with that info, I recommend adding some log statements throughout and see where things are failing. Don't be afraid to drop some logging in vendor/ temporarily to test it out! With more information from where it's triggered, a solution can probably be found.

[Treggats]

@francislavoie as you suggested I put several log statements in vendor.

But the only thing I see are the following methods inside PusherBroadcaster.

PusherBroadcaster@validAuthentionResponse & PusherBroadcaster@decodePusherResponse

The log statements I've put in the TriggerEventController aren't showing up.

[francislavoie]

So you're saying PusherBroadcaster@broadcast isn't hit?

Laravel Echo does an ajax call against the server on /broadcasting/auth -> Illuminate\Broadcasting\BroadcastController@authenticate to check if the user has permission to receive messages on a particular channel. That's when validAuthenticationResponse is going to be hit, that's the function that gets hit internally when that endpoint is called.

PusherBroadcaster@broadcast is called when the event is being sent to laravel-websockets. Your queue worker does the HTTP request to laravel-websockets.

(Did you forget to reload your queue workers after adding the log statements?)

[Treggats]

So you're saying PusherBroadcaster@broadcast isn't hit?

Correct, but only when using the redis queue connection. The sync connection does fire the broadcast.

[Treggats]

After I edit something on the server, I always reload php (opcache) and restart horizon (horizon:terminate)

[Treggats]

It seems I have finally fixed my own issue.

After a deep dive I discovered the following things:

• shouldDiscoverEvents in EventServiceProvider was missing, so it was set to false
• staging and production were using the same redis db

After implementing the shouldDiscoverEvents method and changing the redis db my events are handled and broadcasted

@francislavoie thanks for helping me debug

@MWL91 maybe this is something for you to check?

Closing.