fix: panic in mailserver cycle

[richard-ramos]

Fixes:

panic: send on closed channel

goroutine 2192 [running]:
github.com/status-im/status-go/protocol.(*Messenger).EmitMailserverAvailable(...)
    /Users/anastasiya/status-desktop/vendor/status-go/protocol/messenger_mailserver_cycle.go:761
github.com/status-im/status-go/protocol.(*Messenger).connectToMailserver(0x240015df180, {{0x10edb0969, 0x25}, {0x0, 0x0}, 0x0, {0x10ee2a96a, 0x79}, {0x0, 0x0}, ...})
    /Users/anastasiya/status-desktop/vendor/status-go/protocol/messenger_mailserver_cycle.go:447 +0x6d8
github.com/status-im/status-go/protocol.(*Messenger).findNewMailserver(0x240015df180)
    /Users/anastasiya/status-desktop/vendor/status-go/protocol/messenger_mailserver_cycle.go:359 +0xc20
github.com/status-im/status-go/protocol.(*Messenger).connectToNewMailserverAndWait(0x240015df180)
    /Users/anastasiya/status-desktop/vendor/status-go/protocol/messenger_mailserver.go:104 +0x16c
github.com/status-im/status-go/protocol.(*Messenger).disconnectStorenodeIfRequired(0x240015df180)
    /Users/anastasiya/status-desktop/vendor/status-go/protocol/messenger_mailserver_cycle.go:789 +0x1f8
github.com/status-im/status-go/protocol.(*Messenger).verifyStorenodeStatus(0x240015df180)
    /Users/anastasiya/status-desktop/vendor/status-go/protocol/messenger_mailserver_cycle.go:706 +0xac
created by github.com/status-im/status-go/protocol.(*Messenger).StartMailserverCycle in goroutine 1660
    /Users/anastasiya/status-desktop/vendor/status-go/protocol/messenger_mailserver_cycle.go:92 +0x2f4
SIGABRT: Abnormal termination.
make: *** [run-macos] Abort trap: 6

Requires:

• fix: make mailserver availability subscriptions concurrency safe status-go#5804

[status-im-auto]

Jenkins Builds

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	deeac73	#1	2024-09-05 14:06:03	~6 min	tests/nim	📄log
✔️	deeac73	#1	2024-09-05 14:08:00	~8 min	macos/aarch64	🍎dmg
✔️	deeac73	#1	2024-09-05 14:10:45	~11 min	macos/x86_64	🍎dmg
✔️	deeac73	#1	2024-09-05 14:11:28	~12 min	tests/ui	📄log
✔️	deeac73	#1	2024-09-05 14:15:32	~16 min	linux-nix/x86_64	📦tgz
✔️	deeac73	#1	2024-09-05 14:15:58	~16 min	linux/x86_64	📦tgz
✔️	deeac73	#1	2024-09-05 14:23:21	~24 min	windows/x86_64	💿exe

[anastasiyaig]

@richard-ramos i logged in with account i was able to reproduce the issue and the account was keeping multiple communities , but now there is none recovered. Could it be related to the changes you did or it is due to fact i recovered account several times today within 8h and waku is not giving me anything now? :D

[richard-ramos]

i logged in with account i was able to reproduce the issue

The same panic err? 😮

nvm. I understood now! looking into this

[richard-ramos]

After retrying. The behavior seems to be unrelated.
I tried with the following seedphrase: traffic supreme core life soon voyage satisfy glory engage foil impact riot and was able to observe the communities being restored:

[richard-ramos]

Something that perhaps @saledjenic will want to take a look at is that it seems that when there's a failure executing store node queries, it does not retry them and we have to wait until the 2 min timeout is met to be able to retry. (I did not go deep into the code to confirm so i could be wrong on this observation, so dismiss it if it's the case).

If this is the case perhaps something that could be done is to retry the request automatically, or have the timeout be cancelled immediatly so the user can decide whether to retry or continue anyway.

[saledjenic]

Not sure at all if failed queries are handled in a way that we're requesting data again if they fail, it's more a question for someone from the messenger team.

What I can say is that after the user provides a seed phrase we run the node and that process among others requires history messages from the store node. After the node is run, the client (desktop app) waits for 2 minutes, expecting data to be received, if not, we offer a user an option to re-request data explicitly, then this function is called https://github.com/status-im/status-go/blob/develop/protocol/messenger_mailserver.go#L259-L282, after it, the client waits for 2 minutes again and after that period if data are still not fetched offers the same option again to re-request data and so on.