"participants->update" is sent again and again once a guest left a conversation

[danxuliu]

Since #9412 the HPB endlessly sends participants->update signaling messages to the other participants once a guest left a conversation.

How to test

• Add 'debug' => true, to config.php
• Setup the HPB
• Create a public conversation
• In a private window, open the public conversation as a guest
• Reload the page
• In the original window, open the browser console

Expected behaviour

Some signaling messages are received, but then everything is stable

Actual behaviour

participants->update signaling messages are received again and again; signaling server logs show User map[inCall:0 lastPing:0 participantPermissions:1 participantType:4 sessionId:0] is not in the meeting, ignoring again and again

Originally posted by @danxuliu in #9412 (comment)

[nickvergessen]

Hmm, I can not reproduce this locally neither on sermo, so something else should be triggering the update loop.

But I can see that guests without a session are not excluded on

spreed/lib/Signaling/BackendNotifier.php

Lines 365 to 366 in c1970ca

	} else {
	$users[] = $data;

anymore. We could add that.

[danxuliu]

The problem seems to be a type conversion when the permissions are 0 in the database but the value is returned as a string instead of an integer; I can reproduce the issue locally with SQLite and MySQL (actually, MariaDB), but not with PostgreSQL:

• After the guest leaves the room the database contains a ghost guest:

| id | room_id | actor_type | actor_id                                 | display_name | pin  | participant_type | favorite | notification_level | last_joined_call | last_read_message | last_mention_message | read_privacy | access_token | remote_id | last_mention_direct | permissions | notification_calls |
+----+---------+------------+------------------------------------------+--------------+------+------------------+----------+--------------------+------------------+-------------------+----------------------+--------------+--------------+-----------+---------------------+-------------+--------------------+
|  2 |       2 | users      | admin                                    | admin        | NULL |                1 |        0 |                  0 |                0 |                51 |                    0 |            0 | NULL         | NULL      |                   0 |           0 |                  1 |
|  3 |       2 | guests     | ac350ba8a14d614e778df21f50f28a69108ad170 |              | NULL |                4 |        0 |                  0 |                0 |                51 |                    0 |            0 | NULL         | NULL      |                   0 |           0 |                  1 |

• When the WebUI of other participants fetch the participant list the guests are cleaned
• But if the permissions are not an integer 0 the attendee for the guest is not cleaned
• Nevertheless, EVENT_AFTER_GUESTS_CLEAN is always emitted even if no guest was cleaned
• The handler for EVENT_AFTER_GUESTS_CLEAN notifies the signaling server that the participants were modified
• The signaling server sends a participants->update event to the clients
• The WebUI handles the event by fetching the participant list
• Rinse and repeat