Getting kicked out of community - checked with owner who did not kick me out

[fryorcraken]

Bug Report

Description

Second time that after a weekend of not using laptop (Status desktop kept open) I am getting kicked of Status Inu community on Monday. I checked with owner who did not take such action.

Steps to reproduce

Unsure...

Join Status Inu
Get approved
chat during the week
dont use laptop during weekend
kicked out on Monday

Expected behavior

Only get kicked out when the owner actually does the action

Actual behavior

Getting kicked out without owner action

Additional Information

• Status desktop version: 2.28.1 App Image
• Operating System: Fedora x8_64

app_20240531_145729.log

geth.log:

• https://drive.proton.me/urls/E3HS67YNNM#etYSfpS3TxJi
• https://drive.proton.me/urls/Y1STNH8A4G#Ma2SsWIsDmet

[fryorcraken]

Logs already attached, interesting snippet (I assume):

xt_checkAllCommunityChannelsPermissions
DBG 2024-06-03 10:00:27.095+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=stickers_pending
DBG 2024-06-03 10:00:27.095+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=stickers_installed
INF 2024-06-03 10:00:27.310+10:00 history request started                    topics="mailservers-service" tid=577736 file=service.nim:166 numBatches=2
INF 2024-06-03 10:00:27.310+10:00 history request failed                     topics="mailservers-service" tid=577736 file=service.nim:176 requestId=493324d3e56e82b3ed5becd703ebb4edd10beb21524729849a07724277ea5db6 peerId=16Uiu2HAm9CQhsuwPR54q27kNj9iaQVfyRzTGKrhFmr94oD8ujU6P errorMessage="failed to dial: failed to dial 16Uiu2HAm9CQhsuwPR54q27kNj9iaQVfyRzTGKrhFmr94oD8ujU6P:\n  * [/ip4/8.218.121.232/tcp/30303] dial backoff"
INF 2024-06-03 10:00:27.980+10:00 mailserver not working                     topics="mailservers-service" tid=577736 file=service.nim:161
INF 2024-06-03 10:00:27.980+10:00 active mailserver changed                  topics="mailservers-service" tid=577736 file=service.nim:151 node=/dns4/store-02.ac-cn-hongkong-c.shards.test.statusim.net/tcp/30303/p2p/16Uiu2HAm9CQhsuwPR54q27kNj9iaQVfyRzTGKrhFmr94oD8ujU6P
ACTIVE MAILSERVER CHANGED: ref 0x7fc0eaafec30 --> [nodeAddress = 0x7fbfe478a1a0"/dns4/store-02.ac-cn-hongkong-c.shards.test.statusim.net/tcp/30303/p2p/16Uiu2HAm9CQhsuwPR54q27kNj9iaQVfyRzTGKrhFmr94oD8ujU6P"]
DBG 2024-06-03 10:08:22.040+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=wakuext_getContactByID
DBG 2024-06-03 10:08:22.040+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=wakuext_getTrustStatus
DBG 2024-06-03 10:08:22.041+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=wakuext_getContactByID
DBG 2024-06-03 10:08:22.041+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=wakuext_getTrustStatus
DBG 2024-06-03 10:08:22.041+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=wakuext_getContactByID
DBG 2024-06-03 10:08:22.042+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=wakuext_getTrustStatus
Warning: qrc:/app/AppLayouts/Communities/views/CommunityColumnView.qml:482:9: QML StatusButton: Cannot anchor to an item that isn't a parent or sibling. (qrc:/app/AppLayouts/Communities/views/CommunityColumnView.qml:482, )
DBG 2024-06-03 10:08:22.052+10:00 setCommunityInfo                           tid=577736 file=status_community_link_preview.nim:155 communityId=0x024fa9114e8884d220111653fe9a2095e62c8d0890198ac9787d512d707e276501 communityName="Status Inu"
DBG 2024-06-03 10:08:22.079+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=settings_deleteExemptions
WRN 2024-06-03 10:08:22.080+10:00 trying to get chat data for an unexisting chat id topics="chat-service" tid=577736 file=service.nim:438 chatId=
DBG 2024-06-03 10:08:22.080+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=wakuext_hasUnseenActivityCenterNotifications
DBG 2024-06-03 10:08:22.080+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=wakuext_activityCenterNotificationsCount
DBG 2024-06-03 10:08:22.082+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=wakuext_activityCenterNotificationsCount
DBG 2024-06-03 10:08:22.083+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=wakuext_hasUnseenActivityCenterNotifications
DBG 2024-06-03 10:08:22.083+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=wakuext_activityCenterNotificationsCount
Warning: qrc:/app/AppLayouts/Chat/views/ChatColumnView.qml:162: TypeError: Type error (exception occurred during delayed function evaluation) (qrc:/app/AppLayouts/Chat/views/ChatColumnView.qml:162, )
DBG 2024-06-03 10:08:22.207+10:00 Add AC notification                        topics="notifications-manager" tid=577736 file=notifications_manager.nim:229 title="You were kicked from Status Inu" message=
DBG 2024-06-03 10:08:22.207+10:00 Add OS notification                        topics="notifications-manager" tid=577736 file=notifications_manager.nim:267 title="You were kicked from Status Inu" message= identifier="{\"notificationType\":18,\"sectionId\":\"0x024fa9114e8884d220111653fe9a2095e62c8d0890198ac9787d512d707e276501\",\"isCommunitySection\":true,\"sectionActive\":false,\"chatId\":\"\",\"chatActive\":false,\"isOneToOne\":false,\"isGroupChat\":false,\"messageId\":\"\"}"
/usr/bin/notify-send: symbol lookup error: /lib64/libnotify.so.4: undefined symbol: g_once_init_leave_pointer
Warning: qrc:/app/mainui/AppMain.qml:568: TypeError: Cannot read property 'horizontalCenter' of null (qrc:/app/mainui/AppMain.qml:568, )
DBG 2024-06-03 10:08:27.046+10:00 NewBE_callPrivateRPC                       topics="rpc" tid=577736 file=core.nim:27 rpc_method=wakuext_slowdownArchivesImport

[caybro]

Looks like a duplicate of #14422

[jrainville]

Looks like a duplicate of #14422

Yeah they are definitely related. It seems like playing with the shared addresses popup isn't the source of the issue, since I doubt @fryorcraken did that

[fryorcraken]

Looks like a duplicate of #14422

Yeah they are definitely related. It seems like playing with the shared addresses popup isn't the source of the issue, since I doubt @fryorcraken did that

Indeed, I did not touch the shared address settings beyond setting to "sharing all" when I joined the community.

[osmaczko]

@fryorcraken do you remember by any chance if you were still present on the member list? That will help us understand if it was an issue on your client's side or the control node's side.

@jrainville, I quick guess what happened is, after the weekend, Frank connected to the store nodes and fetched an old community description where he was not yet a member.

[fryorcraken]

do you remember by any chance if you were still present on the member list?

Do you mean by checkign the side panel with the member list? I don't know but I can check next time it happens (if ever).

an old community description where he was not yet a member.

Aren't timestamps used to ensure old community description do not override info received by a more recent description? note that community description messages are broadcast, so afaik, we will not be able to apply an end-to-end reliability protocol to it.
This means that we need to cater for scenarios where community description messages are misordered or missing, even after new reliability related changes are delivered.

[osmaczko]

Do you mean by checkign the side panel with the member list? I don't know but I can check next time it happens (if ever).

Yes. That would be great, thanks.

Aren't timestamps used to ensure old community description do not override info received by a more recent description?

Indeed, we ignore descriptions with older clocks, but since we don't return an error in this case, and just judging by the symptoms, I assumed there might be a code path where we override the community with an older version anyway.

note that community description messages are broadcast, so afaik, we will not be able to apply an end-to-end reliability protocol to it.
This means that we need to cater for scenarios where community description messages are misordered or missing, even after new reliability related changes are delivered.

That's true, we are well aware of that. Misordered case is mitigated by the clock check I mentioned, while missing description is mitigated by broadcasting the description at regular intervals, minimizing the risk of members not receiving the updated version.

[osmaczko]

status-im/status-go#5373 potentially fixes the issue. Please re-open if it happens again, we'll dig further.