V2.x Echo here/leaving not triggering

[AugmentBLU]

Hello, I just started using Laravel-Websockets and decided to check out v2 as I'll be needing redis and multi-server support.

I noticed that Laravel Echo .here() and .leaving() are not being triggered. It was working in version 1 when I first tested, updated to v2 and both functions have stopped working. I have backed down to v1 again and both functions work again.

I realise this is still in beta, just wanted to report or see if it was a known issue.

[AugmentBLU]

An update on my issue.

I updated back to v2 and changed the LARAVEL_WEBSOCKETS_REPLICATION_DRIVER back to local and everything is working as expected.

When switching back to redis, I can see the key/value pairs in my Redis DB that relate to the Laravel-Websocket connections so up to this point it is working. What I can't get to work is broadcasting these pairs that will no doubt trigger the here/leaving functions.

Any pointers on what we should be doing within Laravel to keep an eye on Redis? Usually I have Horizon running but so far this hasn't solved anything.

[rennokki]

We are aware that this is caused by the fact that the Redis replication doesn't work with the presence channels and we're working on a fix, as v2 is needed to reach stability.

Horizon is used for queues, and it has nothing to do with the Redis on the Pub/Sub side.

[rennokki]

.leaving() do get triggered, but .here() is not. I have to investigate this.

[AugmentBLU]

.leaving() do get triggered, but .here() is not. I have to investigate this.

I can confirm, .leaving() does work, .here() does not. Hopefully a fix can be found soon.

Keep up the great work!

[rennokki]

2.x should fix the .here() method :D

Read here the changelog: #447

Make sure to get a new copy of the config file.

[AugmentBLU]

Nice, the .here() method is working.

I have an issue with broadcasts duplicate but will create another thread if I can't figure out what's going on.

[vesper8]

Also just ran into this issue.. .here() works but .leaving() does not and as a result .here() shows a ton of users that are no longer active. I'm using 'local' mode too

@AugmentBLU Does the .leaving() work for you when using 'local' ? It does not for me

Why is this closed @rennokki ?

[rennokki]

@vesper8 I will look into it tomorrow. I have reopened this for now as the problems were signaled for .leaving().

If you can, try to use the redis mode and see if the bug goes away. If it goes, then the local channel manager should be further debugged.

[vesper8]

Hey @rennokki,

I can confirm that using the redis mode makes leaving() work correctly so that's a yay

However I noticed that prior to switching to redis, I had already "joined" with a user who's browser I have closed long ago, but this user remains "online" now

I don't know how to flush this "online" cache ? I don't want to flush all of redis.. and besides this user must be stuck in the "local" mode somehow

It would be useful if there was a command for flushing this data.. you could pass the app id or app name to the command and it would flush everything related to that app ?

On a side note.. I tried running websockets:flush, not realizing that this is only related to statistics, and I received this error:

Flushing the collected WebSocket Statistics...

   Illuminate\Contracts\Container\BindingResolutionException

  Target [BeyondCode\LaravelWebSockets\Contracts\ChannelManager] is not instantiable.

  at vendor/laravel/framework/src/Illuminate/Container/Container.php:1017
    1013▕         } else {
    1014▕             $message = "Target [$concrete] is not instantiable.";
    1015▕         }
    1016▕
  ➜ 1017▕         throw new BindingResolutionException($message);
    1018▕     }
    1019▕
    1020▕     /**
    1021▕      * Throw an exception for an unresolvable primitive.

      +32 vendor frames
  33  artisan:37
      Illuminate\Foundation\Console\Kernel::handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))

[vesper8]

It would also be useful if the dashboard could confirm which "mode" is being used

Of course it would be super awesome if the dashboard would report more statistics.. such as displaying all channels currently subscribed too.. including public, private and presence channels, and displaying how many connections are included in each

[rennokki]

According to the Pusher protocol, there is a maximum amount of 120 seconds since a connection should not pong in order to be automatically be closed: https://pusher.com/docs/channels/library_auth_reference/pusher-websockets-protocol#recommendations-for-client-libraries, and we use it to make sure to close obsolete connections.

Did the connection last more than 120s after you realized the user won't go away from the prsence channel?