Moving emails to spam is often not possible due to server being not reachable

[DonkeeeyKong]

• [x] This is not a feature request (existing functionality does not work, not missing functionality). I will request features on forum or via support.
• [x] I've searched and did not find a similar issue.

Bug in mobile app

Describe the bug When I try to mark a message as spam, I often get the message that the server is not reachable and I am offline and I should try again later. I then have to keep the spam in my inbox which is annoying. This also happens when I am online and my internet connection is working.

To Reproduce Steps to reproduce the behavior:

1. Go to 'inbox'
2. Open an email
3. Click on 'report email'
4. Select 'report as spam'
5. See error (sometimes. In my case more often than not. Usually it takes several tries to be successful.)

Expected behavior Moving messages to spam should be possible regardless of the internet connection. Maybe the message could be just moved to the spam folder first and reporting it could be tried automatically later in case it's not possible right away. Having to keep the spam around until it's possible to report it is annoying. Deleting it without marking it as spam is unsatisfying.

Screenshots

Smartphone (please complete the following information):

• Device: iPhone 12 mini
• OS: iOS 17.5.1
• Version v240.240813.0

Additional context I do believe this does happen on the desktop and webmail as well.

[charlag]

Hi, thank you for the report! It looks like it might be a WebView issue, could you please check the logs (settings -> about -> send logs) for any errors? Thank you in advance

[DonkeeeyKong]

Which logs exactly are you interested in? I found this: Error message: 0: | POST /rest/tutanota/reportmailservice,"dw@asset://app/common-min-TGYEZNrL.js:1:13081\n@asset://app/worker.js:18:31861\n@asset://app/worker.js:18:32608"

2024-08-19T14:03:51.529Z I "error",ConnectionError Error message: 0: | POST /rest/tutanota/reportmailservice,"dw@asset://app/common-min-TGYEZNrL.js:1:13081\n@asset://app/worker.js:18:31861\n@asset://app/worker.js:18:32608"

2024-08-19T14:03:46.221Z I "ws reconnect socket.readyState: (CONNECTING=0, OPEN=1, CLOSING=2, CLOSED=3): 3","state:","automatic","closeIfOpen:",false,"enableAutomaticState:",true
2024-08-19T14:03:46.326Z I "ws connect reconnect:",true,"state:","automatic"
2024-08-19T14:03:46.664Z I "ws open state:","automatic"
2024-08-19T14:03:46.671Z I "New leader status set:",false
2024-08-19T14:03:51.521Z I "[RestClient]","failed request","POST","apis://app.tuta.com/rest/tutanota/reportmailservice",0,"",["accessToken","v","cv","Content-Type","Accept"],"[137 characters]"
2024-08-19T14:03:51.522Z I "[RestClient]","failed request","POST","apis://app.tuta.com/rest/tutanota/reportmailservice",0,"",["accessToken","v","cv","Content-Type","Accept"],"[137 characters]"
2024-08-19T14:04:22.081Z I "ws tryReconnect closeIfOpen:",false,"enableAutomaticState:",true,"delay:",null
2024-08-19T14:04:22.083Z I "ws reconnect socket.readyState: (CONNECTING=0, OPEN=1, CLOSING=2, CLOSED=3): 1","state:","automatic","closeIfOpen:",false,"enableAutomaticState:",true
2024-08-19T14:04:33.487Z I "ws tryReconnect closeIfOpen:",false,"enableAutomaticState:",true,"delay:",null
2024-08-19T14:04:33.487Z I "ws reconnect socket.readyState: (CONNECTING=0, OPEN=1, CLOSING=2, CLOSED=3): 1","state:","automatic","closeIfOpen:",false,"enableAutomaticState:",true
2024-08-19T14:05:07.009Z I "ws tryReconnect closeIfOpen:",false,"enableAutomaticState:",true,"delay:",null
2024-08-19T14:05:07.009Z I "ws reconnect socket.readyState: (CONNECTING=0, OPEN=1, CLOSING=2, CLOSED=3): 1","state:","automatic","closeIfOpen:",false,"enableAutomaticState:",true

I still believe it would be a major UX improvement if messages that are marked as spam were removed from the inbox regardless of connection errors. This behavior is really annoying, when you get a lot of spam that's not automatically moved to the spam folder.

[charlag]

Thank you for the logs. From these logs it just looks like a connection error but it's probably just a symptom of something else. Perhaps there is more info in native logs?

[DonkeeeyKong]

The main issue of this bug report is not that there are connection errors, but the fact that I can't get the spam out of my inbox when there are connection errors. I don't have these issues with moving or deleting emails. Just with marking them as spam. And it is really annoying when you are forced to keep the spam around until some try to report it is successful. Imho spam should be removed instantly from the inbox and if there is a connection error, reporting it to the server should be tried again later automatically – while the email in question is already out of the user's sight. The current behavior forces your users to keep spam they never want to see in their inbox. That's similar to having to keep trash you want to throw away on your working desk and watch it pile up. In my case the first try to report it on my phone is almost never successful. Sometimes it's the second try, sometimes the third try. Sometimes it takes ten tries. Sometimes it works ten minutes later. This is while I am having a working internet connection and using my phone regularly.

[DonkeeeyKong]

Perhaps there is more info in native logs?

You need to be more precise, please. I have no idea which logs you mean and where I can find them.

[charlag]

I understand that this is a part of a bigger issue where there's no automatic replay of mutations from the client side but this is kind of a bigger thing to implement generically & properly (regarding conflicts and such) and this cannot be addressed on the spot, unfortunately.

What I am trying to diagnose is why you run into connection issues while the rest of the app works properly.

Please check the logs file (in the same settings -> about -> send logs) that should be called numbers_native_tutanota.log.

[DonkeeeyKong]

Please check the logs file (in the same settings -> about -> send logs) that should be called numbers_native_tutanota.log.

I don't have that file. I only get xxxxx_main_tutanota.log, xxxxx_worker_tutanota.log and xxxxx_device_tutanota.log.

[charlag]

ah, my bad, it's device one

[DonkeeeyKong]

2024-08-19T13:28:51Z I Start Tutanota with launch options: nil
2024-08-19T13:28:51Z I No need to migrate defaults
2024-08-19T13:28:51Z I folderPath: /var/containers/Bundle/Application/A46090F9-D970-415E-83FA-84E22DF5A3A8/Tuta Mail.app/build
2024-08-19T13:28:51Z I Adding fetch notification operation to queue
2024-08-19T13:28:51Z I AlarmManager rescheduleAlarms
2024-08-19T13:28:51Z I AlarmManager finished rescheduleAlarms
2024-08-19T13:28:51Z I Downloading missed notification with userId O418o45----9
2024-08-19T13:28:51Z I Fetched missed notifications with status code 200
2024-08-19T13:28:51Z I AlarmManager processNewAlarms
2024-08-19T13:28:51Z I AlarmManager Finished processing 0 alarms
2024-08-19T13:28:51Z I AlarmManager rescheduleAlarms
2024-08-19T13:28:51Z I AlarmManager finished rescheduleAlarms
2024-08-19T13:28:51Z I AlarmManager Finished processNewAlarms
2024-08-19T13:28:51Z I Successfully processed missed notification
2024-08-19T13:28:52Z I opening DB for O418o45----9

[charlag]

was this after the error occurred?

[DonkeeeyKong]

Yes. This is the file that was shown at the same time the error from above was logged in the other file.

[charlag]

Odd, thank you for the info, we'll try to find out more. There was a similar report on Android recently