Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sometimes broadcast not coming through #219

Closed
Treggats opened this issue Jul 12, 2019 · 10 comments

Comments

@Treggats
Copy link

@Treggats Treggats commented Jul 12, 2019

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

This comment has been minimized.

Copy link

@MWL91 MWL91 commented Jul 22, 2019

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

This comment has been minimized.

Copy link
Author

@Treggats Treggats commented Jul 22, 2019

@MWL91

This comment has been minimized.

Copy link

@MWL91 MWL91 commented Jul 22, 2019

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

This comment has been minimized.

Copy link
Author

@Treggats Treggats commented Jul 22, 2019

@francislavoie

This comment has been minimized.

Copy link
Contributor

@francislavoie francislavoie commented Jul 29, 2019

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

This comment has been minimized.

Copy link
Author

@Treggats Treggats commented Jul 31, 2019

@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

This comment has been minimized.

Copy link
Contributor

@francislavoie francislavoie commented Jul 31, 2019

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

This comment has been minimized.

Copy link
Author

@Treggats Treggats commented Aug 1, 2019

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

This comment has been minimized.

Copy link
Author

@Treggats Treggats commented Aug 5, 2019

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

@Treggats

This comment has been minimized.

Copy link
Author

@Treggats Treggats commented Aug 7, 2019

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.

@Treggats Treggats closed this Aug 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.