[BUG] session taking forever to do anything

[Gamerdude1634]

Code of conduct

• I have read and agree to adhere to the Code of Conduct

Self-training on how to write a bug report

• I have learned how to write a bug report

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Whenever you send a pic or video to your friends or family members it takes forever to send and receive the message

Expected Behavior

No response

Steps To Reproduce

No response

Android Version

No response

Session Version

No response

Anything else?

No response

[mstroubadour]

I have this issue also, but on iOS.

It always took a long time - meaning several minutes, and often requiring several tries. This has persisted for many months, but in the past few days it's become unusable. The past several images or video still have either not sent, not been received, or both. It's never taken this long in the past, it's definitely a new phenomenon from the past few days.

Things I've tried:

• updating Session to the latest version. I can confirmalso a contact this is happening with is too on the latest version (2.6.2)
• quitting and restarting Session - this would often "jog" it into sending a picture or video, but not anymore
• changing VPN settings to various different locales to force the generation of different, unique paths - no difference at large, though it did work for one image, once about a day ago
• rebooting my phone

To be clear, some of these messages do actually claim to have been "Sent", but have not been received by the other party. In the past, "Sent" would always mean the message would (eventually) be received. Most, however, are not reaching the "Sent" stage.

Text messages continue to work fine.

[KeeJef]

We're looking into this currently, since we have seen many reports of slower than average performance in Session iOS, Android and Desktop, especially when it comes to sending files. We're investigating the rollout of libQUIC, which is supported across all storage servers but only used by the iOS client to communicate instead of http, we think the higher usage of libQUIC might be causing some crashes on storage servers, which are impacting the rest of the network. Will have additional updates over the next week as we investigate

[mstroubadour]

If it's helpful, over the past four days, myself and a contact have attempted to send 15 images/video, ranging in size from 20KB to 2MB. Only three have been received, so it's an 80% failure rate for images and video over this time period.

Possibly useful to add - I also tried sending specific-length text messages (containing random data to avoid compression affecting resultant size), up to about 16KB - 32KB per message. I'm not sure on the resultant size as it would depend how Session encodes text (8-bit or 16-bit for ASCII?). None of these messages seemed to trigger the same behaviour, and all of our text messages seem to go through fine.

[mstroubadour]

Just an update - it's been impossible to send images or video over Session for the past two days. The failure rate has been 100%. Text continues to work fine. This is on iOS Session 2.6.2 -> iOS Session 2.6.2.

One time I received a pop-up error "13", which I looked up in the code and it was a timeout.

Possibly related: since upgrading to Session 2.6.2, immediately prior to chiming in on this thread (from a much earlier version, 2.3.x), Session is absolutely trashing the iPhone battery. My phone is heating up when Session is left running, and it's been responsible for over 50% energy usage versus 10+ other apps. Never used to do this on 2.3.x or earlier.

[mstroubadour]

Afterthought: given it's a presumably an edge-case to have so many high-bandwidth media messages in the queue that have failed to send, and given they are also stressing the servers, I wonder if some kind of race-type condition is happening in the background.

Ok, to examine this - I just exported the logs from my client, and I'm getting multiples of:

• Testing guard snode
• Error sending packets
• Network is unreachable

In a loop, repeating about every 200ms, with messages every few ms, constantly (for minutes at a time). I'm guessing the servers might then tag this behaviour as a DoS, leading to the constant failures?

Ie, this may end up being a difficult condition for you to trace, as valid clients could be being mis-categorised by the server, and in the server logs, possibly leading to a kind of automatic "censorship" of valid clients, and of the issue from your end?

[KeeJef]

How has it been in the last day or so? Service Nodes are beginning to upgrade so we should be seeing the incidence rate go down, although we are still only at around 50% of the network thus far

[mstroubadour]

For the most part, it's the same end result here, but something has markedly changed in the log files and in the behaviour.

Eg, after consistent failure for attachments, I did a few minutes ago receive the last image that had been sent from a contact a couple of days ago (but none of theirs from the days prior - some of which I just now explicitly hit retry on).

Also, just now a few of mine to them claimed to have been successfully sent almost immediately, however another is instead behaving as before and retrying repeatedly. None have been received yet.

The pattern in the log file, which was previously a very consistent set of repeating errors, has definitely changed. That pattern is absent, and now there's a lot of repeats of:

- Received no new messages in Main Poller after [~]0.89s

And sometimes repeats of:

- LibSession: Attempted to access suspended network

[mstroubadour]

Still unresolved here.

A bunch of my contacts previously-sent images came through to me, but they've still received none of mine since this began. Also, new images I tried to send them just retry over and over, and they haven't been able to send me new ones.

The logs have many network timeouts on attachment uploads/downloads, and more recently, this:

[libSession:quic] [timestamp] Error sending packets {IP -> IP}: Network is unreachable

Text messages still working fine.

[mstroubadour]

It's been two weeks now, and the core messenger functionality of sending images, video or files is still completely broken for me and my contacts. I've evangelised several people to Session over the years I've used it. Now, it's difficult to continue myself, let alone convince others who've become disillusioned/frustrated, and I'm sadly looking for alternatives - which is hard, and sad, because so far only Session has ticked all the right boxes.

But, I have to face the reality that Session doesn't work for sending anything other than text anymore, and much worse than that, for something this impactful and serious: there seems to be very little "official" communication about it other than two messages on this lone github issue. Finally, when a fix is - confidently - deployed, it doesn't work.

I'm also concerned about the general nature of Sessions communication about all of this. It feels minimising. I can't find initial public announcements about this anywhere (maybe I'm not looking in the right places? Please direct me if so). And, here on this issue, the way this was described as "slower than average performance" is very wrong, at least in my case. The reality for me and those I'm communicating with is core functionality is completely broken.

And importantly, how big is the subset of users believed to be affected by this? Why has this not been communicated clearly? Surely it's a known quantity from server logs?

As an estimate of how many of us may be impacted, I took the number of emoji-reacts from the "fix" announcement on the Session updates group, and divided them into the average of emoji-reacts for previous update messages that affect everyone. I think it's a reasonable metric, as predominantly those aware of and impacted by this particular issue will be the ones reacting to a report of a fix of it, whereas anyone and everyone is equally likely to react to a general app update concerning new features, etc.

Anyway, the value came out at about 12%, or about 1 in 8 users. The reality is it may be higher, as when something this serious breaks, for this long, I would expect most people to just switch to something else - and after they're habituated, they won't be checking the old app for updates anymore.

Where do we get stats on Session's unique users and how that's been affected by this?

[KeeJef]

It's been two weeks now, and the core messenger functionality of sending images, video or files is still completely broken for me and my contacts. I've evangelised several people to Session over the years I've used it. Now, it's difficult to continue myself, let alone convince others who've become disillusioned/frustrated, and I'm sadly looking for alternatives - which is hard, and sad, because so far only Session has ticked all the right boxes.

The release, which we think will address the network instability issue, started rolling out to Service Nodes last Thursday. It took us a little bit to discover exactly what the issue was and implement the correct fix. Additionally, with the launch of the Session Token testnet, some of our core resources are stretched quite thin. Currently, about 85% of nodes have installed the updated package, and on the 22nd, the update will be enforced, kicking off non-updated Service Nodes. It really sucks that this is affecting many users who you recommended to use Session. We are working our hardest to fix the issue, but we are somewhat limited by the speed at which operators respond to update requests.

This issue is particularly nasty in that it affects onion requests, which require three randomly chosen Service Nodes to communicate with each other. If you have even one un-updated node in your path, it can cause issues. This means that even with 85% of the network upgraded, the chance of having a path with a least one node that has the old version of the software is 40% which is still quite high.

But, I have to face the reality that Session doesn't work for sending anything other than text anymore, and much worse than that, for something this impactful and serious: there seems to be very little "official" communication about it other than two messages on this lone github issue. Finally, when a fix is - confidently - deployed, it doesn't work.

We have put out communication through a number of channels over the past week, here https://t.me/OxenAnnouncements/782 , https://x.com/session_app/status/1812752211115708545 , https://x.com/session_app/status/1811267901753856140 , https://x.com/JefferysKee/status/1813104572128280641 , and through the Session updates channel

I'm also concerned about the general nature of Sessions communication about all of this. It feels minimising. I can't find initial public announcements about this anywhere (maybe I'm not looking in the right places? Please direct me if so). And, here on this issue, the way this was described as "slower than average performance" is very wrong, at least in my case. The reality for me and those I'm communicating with is core functionality is completely broken.

The issue has gotten worse over time, as more iOS users have upgraded to use the new libQUIC code, which causes more crashes on the Service Node storage server. Initially when iOS libQUIC use was low, Session would switch paths and handle the failing nodes, and it would appear slower. As more Service Node storage servers ran into the issue due to more iOS users updating, the capacity to interact with parts of the network became worse, to the point that it was nearly impossible to send a file. So at the start, I think the description was fine, but it has changed over time.

And importantly, how big is the subset of users believed to be affected by this? Why has this not been communicated clearly? Surely it's a known quantity from server logs?

As an estimate of how many of us may be impacted, I took the number of emoji-reacts from the "fix" announcement on the Session updates group, and divided them into the average of emoji-reacts for previous update messages that affect everyone. I think it's a reasonable metric, as predominantly those aware of and impacted by this particular issue will be the ones reacting to a report of a fix of it, whereas anyone and everyone is equally likely to react to a general app update concerning new features, etc.

We don't know the exact number of users impacted because we don't run the vast majority of Service Nodes on the network. We don't know how many users are storing files, failing to store files, or having other network-related issues, we can only estimate based on what we see and hear, this is one inherent limitation to not deploying in-app analytics/trackers . Emoji reacts on the Session Update post wouldn't be a super accurate way of measuring the fix. As I said before, around 40% of paths will still likely have issues, the issue is unlikely to be fully fixed until the 22nd. However, as more nodes upgrade, the frequency of issues should reduce.

Anyway, the value came out at about 12%, or about 1 in 8 users. The reality is it may be higher, as when something this serious breaks, for this long, I would expect most people to just switch to something else - and after they're habituated, they won't be checking the old app for updates anymore.

Where do we get stats on Session's unique users and how that's been affected by this?

I agree with you. I expect Session will lose some users over perceived bugginess in the application. We're doing our best to address these issues, but we're not currently meeting user expectations. I encourage you to hang in there while we do. The last few weeks have been though, but I can see the light at the end of the tunnel, and it think won't be long before the network gets back to normal.

[mstroubadour]

@KeeJef Thank you for your detailed and quick reply. It's given me the confidence to carry on, and I really appreciate that. As I mentioned, Session is the only privacy-respecting messenger I've found that genuinely seems to do everything I'd expect such an app to do. When I first found Signal years ago, I thought "this is fantastic but they've totally screwed it by requiring phone numbers", and initially thought of forking it to try figure out how to fix that. I was very happy to discover Session had already done it.

Thanks also for linking the other communications channels. That would've been a big help for me to see earlier, especially the OxenAnnouncement with technical details and timeline. Somehow I didn't find these, maybe it's on me I didn't look hard enough.

It's great I can share this thread, especially how professional and open your response was, and maybe keep others from jumping ship just yet, as one thing I spent time explaining recently to hopefully help keep folks on-board, is the difficulties involved in managing a decentralised system versus a centralised one. It's always more meaningful coming from the devs directly and with full technical details, as I could only guess at them.

Though tangential, some detail on what I found throughout this may be useful for Session to consider:

To I suspect many users, Session is perceived as "just another messenging app but with better privacy and anonymity". The problem is the first part is inaccurate. It's not just another messenging app. It's a messenging app built on top of a completely decentralised network. The importance of this distinction gets revealed when users will find it unacceptable that it doesn't "just work", like one of its centralised contemporaries demonstrably will by comparison. We understand why that is and how users data is exploited to pay for the centralised infrastructure making that all "work". But users don't.

The solution of course is education. I believe your users should understand the trade-offs and benefits when moving to decentralisation from centralisation - and not have it sugar-coated or marketed past. The decentralised app, for all intents and purposes, should reasonably be expected to not be as good in key ways such as latency or uptime - at least at the outset - until there's enough of a critical mass of infrastructure, operators and resilient code. This is the price paid for a privacy-respecting, secure and anonymous system, but I suspect many users are not aware there is a price, nor why.

Obviously, that needs to be handled carefully as you can't very well sell something as inferior to its competition, but I think something would be good to be done to address the knowledge gap, as that would hopefully keep users from jumping ship too early if (when) something like this happens again.

Anyway, thanks again, and I'll update as hopefully things improve over the next week.

[mstroubadour]

Pleased to report that since the 2.6.3 app update everything seems to be working! That's for sending and receiving media/files between any contacts who's also updated. Sending media/files also seems snappier than before.

Thank you for all your hard work, and for your comprehensive engagement throughout, it really meant a lot.

[KeeJef]

Good to hear that the recent round of updates have brought Session back to a higher level of reliability, similar updates have gone out on Android (version number 1.18.5/6) and Desktop (version number 1.12.5). Closing this issue for now 👍