Confusing Error "Connection Error While Uploading Answers" - Due to known OSM read only mode

[peternewman]

Due to https://community.openstreetmap.org/t/openstreetmap-org-currently-offline-operations-team-are-working-to-restore-15-december-2024/122930 the OSM database is currently in read only mode.

Download currently works fine, but upload fails with "Connection Error While Uploading Answers". If you look in the log, you get a more informative message that it's a 503 with "Database offline for maintenance".

How to Reproduce
Have an outage such as https://community.openstreetmap.org/t/openstreetmap-org-currently-offline-operations-team-are-working-to-restore-15-december-2024/122930

Expected Behavior
While I appreciate it wouldn't be translated, it might be nice to show the error from the server in a more direct way than having to dig in the logs.

I also wonder if there should be a pair of error messages, with one trying to match an inability to reach the API (e.g. due to being on a private network, or stuck behind a captive portal) and another when there is a problem with the API itself (e.g. 5xx errors) so they could ideally be a bit more descriptive.

Maybe even try accessing westnordost's website too in the event of a failure to try and narrow down a likely cause (given SC is in the fairly unique position of having two independently hosted APIs it can hit/test).

Versions affected
v59.3

[matkoniecz]

While I appreciate it wouldn't be translated, it might be nice to show the error from the server in a more direct way than having to dig in the logs.

Note that error from the server is actually more misleading and confusing as database is offline not really for maintenance but awaits (for multiple days!) replacement of broken router from ISP (on ISP side, they plugged two independent lines into the same device for which they had no working spares).

[taxmeifyoucan]

+1 It's confusing to display a general connection error when the issue is known to be on the server, I was checking my network settings and VPN before figuring it out in app logs.

on ISP side, they plugged two independent lines into the same device for which they had no working spares

Logs show server returning 503 so backend is offline but it would be hilarious to have this specific error :)

[westnordost]

I think the current error is just fine. For the user it doesn't matter whether the server responds with an "Error, but it's my fault!", if the server responds with garbage data or if the server is not reachable at all due to some network error. From the perspective of the user, it doesn't work because for one reason or another, the server cannot be connected to. And in all of these cases, what the user should do is to try again later. I believe this is what is being shown to the user, right? That he should try again later?

[matkoniecz]

@taxmeifyoucan suggests to distinguish "your internet is broken altogether, maybe check whether you paid for mobile internet etc" from "OSM servers cannot be reached, try later"

[mnalis]

From the perspective of the user, it doesn't work because for one reason or another, the server cannot be connected to

Well, I might agree as far as "if the server returns the error, it doesn't matter to user exactly what the error is" (although, as an techie, I'd personally still very much like to know!)

But, I disagree that it doesn't matter whether it is network error or server error. Although user cannot do anything about server errors, even relatively many non-technical users can try to do something about connection errors (e.g. disable wifi and enable mobile data or vice versa; disable their VPN or similar etc).

---

In general, I think dumbification of error messages is not helpful. Not for newbie experts (who are eventually going to try to ask someone more knowledgeable, but would then be unable to provide details, so nobody will be able to help them) and especially not for more advanced users.

Even if one were to still insist on showing dumbified error message in order not to frighten the users or whatever, they should then provide button "Technical information details" which shows actual low-level error cause (e.g. Socket error number, verbatim API server response etc)

[matkoniecz]

Not sure whether I want to go as far as to declare that such debug should be definitely always available.

[peternewman]

Yeah @taxmeifyoucan probably put it better than me.

I think the current error is just fine. For the user it doesn't matter whether the server responds with an "Error, but it's my fault!", if the server responds with garbage data or if the server is not reachable at all due to some network error. From the perspective of the user, it doesn't work because for one reason or another, the server cannot be connected to.

I believe this is what is being shown to the user, right? That he should try again later?

I'd argue the current error is too specific "Connection Error While Uploading Answers" implies to me that there's an issue getting to the server, which could well be my problem to solve. Hence my suggestion of splitting it into two error messages.

If you wish to keep just the one error message, I think dropping the word "Connection" would actually help things, as people won't immediately go checking their own network connection, or won't assume that is all that is at fault.

Which is actually what was in place until:
5662d03

StreetComplete/app/src/main/res/values/strings.xml

Lines 66 to 67 in 5662d03

	<string name="download_error">"Error while scanning for quests. Please check the log"</string>
	<string name="upload_error">"Error while uploading answers. Please check the log"</string>

Like @mnalis I'd like to see the actual API error, although at least its not too hard to fetch from the logs if it isn't added to the display.

Note that error from the server is actually more misleading and confusing as database is offline not really for maintenance but awaits (for multiple days!) replacement of broken router from ISP (on ISP side, they plugged two independent lines into the same device for which they had no working spares).

Pedantically it's still maintenance, it's just its the maintenance of the ISP router rather than the DB itself! :) The first part was fine anyway. But more importantly it tells me it's a them issue, not a me issue.

In fact it looks like the granularity of error data is already available in the code, and it's just being coerced into a smaller subset of exceptions within SC, so aside from the translation effort this is just a minor code change:
https://github.com/streetcomplete/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/data/ApiClientExceptions.kt