Open eugenesan opened 1 year ago
Strange, were you restoring after more than 14 days of inactivity on any device? we will be tackling the restoration process in an upcoming release which should improve this process
Strange, were you restoring after more than 14 days of inactivity on any device? we will be tackling the restoration process in an upcoming release which should improve this process
Yes, there was no activity for a while but that didn't affect restoration on a Desktop version.
Sounds like it might be an Android specific issue where if the user cannot find their config message they get into a stuck state, this will be fixed in an upcoming release
Sounds like it might be an Android specific issue where if the user cannot find their config message they get into a stuck state, this will be fixed in an upcoming release
Tested 1.16.7 release and it is still broken. Did you mean the issue to be fixed in a bigger release, like 1.17.0?
Yeah it will be fixed in the upcoming user configuration release, could be other releases before then
I am also facing this problem plz solve it asap.
Having the same issue. Forever loading after entering the recovery phrase. OS: GrapheneOS AOSP 13.
Fix this issue as soon as possible please, I'm not able to log in to my account!
Having the same issue. Forever loading after entering the recovery phrase. OS: GrapheneOS AOSP 13.
Fix this issue as soon as possible please, I'm not able to log in to my account!
What version of Session are you using? Also have you tried the link a device flow vs the continue your Session flow?
the latest, Session v1.17
FYI, multiple people are reporting on reddit that they're encountering this problem. https://www.reddit.com/r/Session_Messenger/comments/15a2hmj/session_recovery_taking_very_long_time/ https://www.reddit.com/r/Session_Messenger/comments/168y8je/cannot_recover_session_on_new_phone/
I'm seeing it on Android 13, Session app 1.17.0
Does anyone have device logs for this issue? Does the toast notification appear asking if you would like to skip the restore process?
Does anyone have device logs for this issue? Does the toast notification appear asking if you would like to skip the restore process?
I don't have the logs but the toast notification does appear after some time. Also since a couple versions ago, even if fails and proposes to "skip" it somehow restores the session. Not sure if that behavior is consistent but it did work for me on two devices (not eager to retry and risking not being able to restore).
So this case can occur naturally, if all your devices are offline for a period of more than 30 days then your configuration message will expire in your swarm and the client device will be unable to find it. In this case the skip option is offered so that the user can still restore using the same key, but they will not be able to restore any contacts, groups, profile images, usernames etc... Not sure if these cases were occurring after roughly 30 days of inactivity?
So this case can occur naturally, if all your devices are offline for a period of more than 30 days then your configuration message will expire in your swarm and the client device will be unable to find it. In this case the skip option is offered so that the user can still restore using the same key, but they will not be able to restore any contacts, groups, profile images, usernames etc... Not sure if these cases were occurring after roughly 30 days of inactivity?
I believe Desktop instance was active recently or at the same time. Several minutes after "skipping" config fetch, new mobile instance synced with Desktop instance.
I wonder if "config in the swarm" is device, platform, network or session specific? Mobile instances often reside behind at least one NAT6 with frequently changing routing. Though, restoring session on Desktop app works just fine even when using the same mobile device as a hotspot...
In my case at least, the "skip" option does NOT restore the session - it just takes me to "Pick your display name" as if creating a new ID.
I'm trying this on a new phone, while I currently have session running and my conversations showing on both my laptop (mac) and my iPad. Both are "active", and I've sent and received messages in the past few days. So inactivity doesn't explain it.
In my case at least, the "skip" option does NOT restore the session - it just takes me to "Pick your display name" as if creating a new ID.
I'm trying this on a new phone, while I currently have session running and my conversations showing on both my laptop (mac) and my iPad. Both are "active", and I've sent and received messages in the past few days. So inactivity doesn't explain it.
When you press skip and enter a display name does it restore your previous conversations, or is nothing restored?
is there any timeline to fix this problem? one would think having multiple linked devices is a core feature of any messaging app.....
Yes, the fix will be part of the onboarding project which will should come some time early next year
This bug is still happening in 1.17.5 on Android 12 with restoring. Is there another method to restore? I cant get my old "account" working on my phone
This bug is still happening in 1.17.5 on Android 12 with restoring. Is there another method to restore? I cant get my old "account" working on my phone
We are planning a fix for this issue. Currently, you can bypass the restoration process and continue to receive new messages. However, messages received on other linked devices less than 14 days old won't be accessible.
I tried to visit the URL
seed2.getsession.org:4443
then got an warning "NET::ERR_CERT_AUTHORITY_INVALID". It seemed to be caused by HSTS failure.
The HSTS is not working with the self-signed certificate on that server. Android will check and enforce this for you, so your app can't connect to an invalid https configuration without you handling the connection in your app yourself.
You will need to put a valid certificate in place for most things to be able to connect.
The value of the HSTS should be reduced too if you aren't planning to maintain a valid certificate for that hostname and port combination.
@KeeJef
The HSTS is not working with the self-signed certificate on that server. Android will check and enforce this for you, so your app can't connect to an invalid https configuration without you handling the connection in your app yourself.
This seed node issue is resolved in new versions of Session, we are using self signed certificates which are distributed in the Session builds and we needed to update those certificates, old versions of Session are still trying to authenticate to the seed nodes with those old certificates.
same issue here, changed the ROM on my phone, but can't recover the session (choosing skip let me in, but can't recover messages anyway)
Just an update on this: We have begun actively working on the Onboarding project, which includes a fix for this problem. We are now about halfway through completing this project on all platforms.
I need to move my account to a new device. Is there any ETA? I cannot keep my old device all the time with me
I need to move my account to a new device. Is there any ETA? I cannot keep my old device all the time with me
You might just have to restore and skip for now, it will still be some time before updated onboarding is released
Well damn...but ok, such is life. Good luck fixing it
Is this issue not fixed yet? I still have this and i am also trying to get on a new phone
We have an update in review on the store that should help with some issues. But we also have our new onboarding release coming out soon after which rethinks the onboarding process. Sorry for the inconvenience...
"Continue Your Session" never finishes after entering Recovery Phrase. It just stays on the same screen forever with progress indication (three flashing dots) and after some time "This is taking awhile, would you like to skip" notification appears which offers to start a "New Session".
Device: Pixel 4a (tested on two separate devices) Network: Tested on 2 different mobile networks (Desktop version is working just fine) OS: Android 13 (last two updates were tested) App: Last two Google Play versions were tested