Editing shared addresses leads to very slow requirements check

[anastasiyaig]

DBG 2024-12-10 17:19:42.283Z id doesn't have expected length            topics="contacts-service" tid=1369871 file=service.nim:348
error compressPk: invalid public key format, '[]'
DBG 2024-12-10 17:19:42.285Z [threadpool task thread] initiating task   topics="task-threadpool" tid=1369896 file=threadpool.nim:56 messageType=AsyncGetRevealedAccountsArg:ObjectType threadid=1369896 task="{\"$type\":\"AsyncGetRevealedAccountsArg:ObjectType\",\"communityId\":\"0x02b5bdaf5a25fcfe2ee14c501fab1836b8de57f61621080c3d52073d16de0d98d6\",\"memberPubkey\":\"0x044f721e6e65bc7338f21f6f16d531afc6435835bb70a79f228553a18a8e247d270233eea110c10ac1c84a6ad5c825a34582d9e7dfef6ad2f73f4da1002171c39b\",\"vptr\":105553140735136,\"slot\":\"onAsyncGetRevealedAccountsForMemberCompleted\"}"
DBG 2024-12-10 17:19:42.287Z NewBE_callPrivateRPC                       topics="rpc" tid=1369896 file=core.nim:27 rpc_method=wakuext_getRevealedAccounts
DBG 2024-12-10 17:19:42.301Z [threadpool task thread] initiating task   topics="task-threadpool" tid=1369892 file=threadpool.nim:56 messageType=AsyncCheckPermissionsToJoinTaskArg:ObjectType threadid=1369892 task="{\"$type\":\"AsyncCheckPermissionsToJoinTaskArg:ObjectType\",\"communityId\":\"0x02b5bdaf5a25fcfe2ee14c501fab1836b8de57f61621080c3d52073d16de0d98d6\",\"addresses\":[],\"vptr\":105553140735136,\"slot\":\"onAsyncCheckPermissionsToJoinDone\"}"
DBG 2024-12-10 17:19:42.301Z NewBE_callPrivateRPC                       topics="rpc" tid=1369892 file=core.nim:27 rpc_method=wakuext_checkPermissionsToJoinCommunity
DBG 2024-12-10 17:19:42.301Z [threadpool task thread] initiating task   topics="task-threadpool" tid=1369895 file=threadpool.nim:56 messageType=AsyncCheckAllChannelsPermissionsTaskArg:ObjectType threadid=1369895 task="{\"$type\":\"AsyncCheckAllChannelsPermissionsTaskArg:ObjectType\",\"communityId\":\"0x02b5bdaf5a25fcfe2ee14c501fab1836b8de57f61621080c3d52073d16de0d98d6\",\"addresses\":[],\"vptr\":105553140734912,\"slot\":\"onAsyncCheckAllChannelsPermissionsDone\"}"
DBG 2024-12-10 17:19:42.303Z NewBE_callPrivateRPC                       topics="rpc" tid=1369895 file=core.nim:27 rpc_method=wakuext_checkAllCommunityChannelsPermissions
WRN 2024-12-10 17:19:43.982Z qt warning                                 topics="qt" tid=1369871 text="TypeError: Cannot read property 'name' of undefined" file=qrc:/app/AppLayouts/Communities/panels/SharedAddressesAccountSelector.qml:63 category=default
INF 2024-12-10 17:20:19.945Z history request failed                     topics="mailservers-service" tid=1369871 file=service.nim:180 requestId=5970e3dbd9144772cae80614f6b67b355d206d12de1e23f5208d754929da1bc6 peerId=16Uiu2HAmJnVR7ZzFaYvciPVafUXuYGLHPzSUigqAmeNw9nJUVGeM errorMessage=EOF
INF 2024-12-10 17:20:19.945Z history request failed                     topics="mailservers-service" tid=1369871 file=service.nim:180 requestId=c8157bd032bc3801c1ccb331f9d652ac1bb0194aeb885a4b14f78532626d2c98 peerId=16Uiu2HAmJnVR7ZzFaYvciPVafUXuYGLHPzSUigqAmeNw9nJUVGeM errorMessage=EOF
INF 2024-12-10 17:20:28.012Z history request failed                     topics="mailservers-service" tid=1369871 file=service.nim:180 requestId=3c1c220ff2c838ac8a1009935291add91b428c8f893659915df4fcc96047e0a3 peerId=16Uiu2HAmJnVR7ZzFaYvciPVafUXuYGLHPzSUigqAmeNw9nJUVGeM errorMessage=EOF
INF 2024-12-10 17:20:28.015Z history request failed                     topics="mailservers-service" tid=1369871 file=service.nim:180 requestId=2db53397fb0dcbf209ae9618957cfd3ab19c446e79e1c16a49ca74fbc48a8302 peerId=16Uiu2HAmJnVR7ZzFaYvciPVafUXuYGLHPzSUigqAmeNw9nJUVGeM errorMessage=EOF
INF 2024-12-10 17:20:28.015Z history request failed                     topics="mailservers-service" tid=1369871 file=service.nim:180 requestId=484c76d48d6fd52f004cb9abc84cc6f3f7b67a2475a91ace3533a032bdb68664 peerId=16Uiu2HAmJnVR7ZzFaYvciPVafUXuYGLHPzSUigqAmeNw9nJUVGeM errorMessage=EOF

[anastasiyaig]

@jrainville dunno whats the plan for the communities, maybe we need to wait for the roadmap to figure out how important the issue is

[caybro]

@jrainville dunno whats the plan for the communities, maybe we need to wait for the roadmap to figure out how important the issue is

imho this is quite important; w/o this you won't be able to join any (token gated?) community

[anastasiyaig]

okay i waited for around of 10 minutes and the check has been completed. Its not infinite but very slow

[jrainville]

okay i waited for around of 10 minutes and the check has been completed. Its not infinite but very slow

Wow, that's a crazy long amount. It used to be slow, but max one minute.

Was it freezing or it just took a long time for the checking to be done (spinner kept spinning)?

@jrainville dunno whats the plan for the communities, maybe we need to wait for the roadmap to figure out how important the issue is

If this issue is reproducible easily, I think it's worth to fix it as it makes the joining of the community seem broken for people that want to edit their shared address

[anastasiyaig]

there was a spinner all the time for the button

[jrainville]

I just tested on master with my main account (ran in dev) and it works fine for me. I do have the banner at the top and it doesn't show my tokens correctly, but it did show me the right permissions I'll have (TokenMaster).

And it was relatively quick, less than a minute.

I wonder if maybe your API keys were at the end of their limit and it had to retry over and over or something like that? @anastasiyaig if you try tomorrow during your morning, we could maybe confirm this hypothesis.

[anastasiyaig]

@jrainville i was using the build from jenkins but sure, i will try more tomorrow. Maybe there is any of impact because i imported the keypair as my second one (not status one)?

I have another thought.
When installing a build (rc3 , clean) i imported one of my old accounts that i keep test funds on. This account was used as my main one long time ago, and it is a member of Status community, however i dont use it for community anymore

Then i imported one more account, which i mainly use with Status community and where i keep my funds to burn when testing transactions.

I guess that could be the case , when status app has 2 accounts which are members of the same community? Maybe this is why the check is getting slower than usual?
I did not realise that when opening a ticket

[jrainville]

I guess that could be the case , when status app has 2 accounts which are members of the same community? Maybe this is why the check is getting slower than usual?

Maybe? It's for sure not a case we tested before. I'm not sure how it could influence from the top of my head though. Maybe @osmaczko has an idea since he worked on the permission checks.

[anastasiyaig]

@jrainville i tested today again, recovered just one account (my main one) and tried to do the permission check. It took me 5 minutes 52 seconds Oo

also, another thing that i noticed is that communities recovered (the list of communities on the left pane) are only recovered for Status keypair, so if i have additional keyparis imported, then communities wont show up besides the ones that belong to Status keypair

Thats not related to the initial problem i am trying to debug but maybe we need to check on that separately too?

[jrainville]

It took me 5 minutes 52 seconds Oo

Ok, so there is something that makes it much slower for you. Maybe something with location? We can ask someone else from Europe to see if it's that.

also, another thing that i noticed is that communities recovered (the list of communities on the left pane) are only recovered for Status keypair, so if i have additional keyparis imported, then communities wont show up besides the ones that belong to Status keypair

Thats not related to the initial problem i am trying to debug but maybe we need to check on that separately too?

We don't sync using the "wallet accounts", but only the main multiaccount, ie the one used during onboarding.

In theory, we probably could sync using the imported wallet accounts too since we'll have access to the public key and thus the right topics to fetch from, but I wonder if it's worth it (we would double the amount of requests).

So in this case, I would suggest that we should find a way to convey to the user that only the main account does the syncing?

[osmaczko]

I would like to clarify few things.

I guess that could be the case , when status app has 2 accounts which are members of the same community? Maybe this is why the check is getting slower than usual?

What do you mean by account? Wallet account or Status chat account? If the former, then what do you mean by saying: wallet account is member of a community? Did you mean wallet account satisfies the criteria of the community? If the latter, then how would that matter, as you can be logged in only one at a time?

also, another thing that i noticed is that communities recovered (the list of communities on the left pane) are only recovered for Status keypair, so if i have additional keyparis imported, then communities wont show up besides the ones that belong to Status keypair

What do you mean by Status keypair and additional keypairs? Do you mean, by Status keypair, a master keypair from which Status chat account and wallet accounts are derived?

We don't sync using the "wallet accounts", but only the main multiaccount, ie the one used during onboarding.

In theory, we probably could sync using the imported wallet accounts too since we'll have access to the public key and thus the right topics to fetch from, but I wonder if it's worth it (we would double the amount of requests).

I am very confused. We sync using Status chat account, sync is a chat feature. Why would we want to sync using the imported wallet accounts? What would we want to sync exactly in this scenario?

[anastasiyaig]

@osmaczko i have no idea. All i am saying, i had 2 accounts in the app that both are members of the same community (different chat keys). I was just guessing what could lead to permission check being very slow on my end, as it takes almost 6 minutes

[osmaczko]

@osmaczko i have no idea. All i am saying, i had 2 accounts in the app that both are members of the same community (different chat keys). I was just guessing what could lead to permission check being very slow on my end, as it takes almost 6 minutes

But there is only one account logged at the time, right? And how can second account not be a Status account?

[anastasiyaig]

one is status account(import seed from onboarding), other one is added from wallet via import seed

[osmaczko]

one is status account(import seed from onboarding), other one is added from wallet via import seed

So you referred to the wallet accounts, one default account generated by Status and another imported account. Saying that a wallet account is a member of a community is technically incorrect. It is not the wallet account that belongs to the community, but rather the chat account. These accounts are distinct and use different keys.

To rephrase, the issue is that if you have more than one wallet account satisfying the criteria for the community, the permissions check takes longer?

[anastasiyaig]

i checked today and having even my one account imported , the permission check is very slow. Its not the case for Jo, so its hard to replicate.