Sync service: provide more precise errors

[bnjbvr]

Notably, it would be nice to distinguish a sliding sync reset, which is not really a hard error, from other timeouts, DNS errors, and so on.

[pixlwave]

Some more useful errors would be when the sync proxy is unreachable and when the /sync endpoint doesn't exist at the given host - specifically this would provide the information for clients to alert new users that there's a configuration issue with their well-known not pointing to the right host.

[morguldir]

Someone in #element-x-ios was having issues with logging into their base domain (no rooms loading), but the subdomain worked fine, this was because their subdomain had a well-known pointing at the proxy matrix.example.org/sliding-sync, but their domain was pointing at matrix.example.org, which is not a proxy, but synapse:

{"errcode":"M_UNRECOGNIZED","error":"Unrecognized request"}

I've also seen quite a few people run into this when they try to set up the proxy via nginx, and they put the synapse location first, so the sync requests don't go to the proxy (/client might still work)

I'm not sure what a good way to avoid this would be, but perhaps a warning if the endpoint repeatedly 404's?

[Hywan]

The log should display the request and the response of the HTTP payloads. I'm not sure it's the role of matrix_sdk_ui::SyncService to display these errors. At worst, it should be matrix_sdk::SlidingSync itself, but again, it uses the matrix_sdk::Client, which logs everything. Is there an access to the logs?

[pixlwave]

I'm not sure it's the role of matrix_sdk_ui::SyncService to display these errors.

The service doesn't need to "display" the errors, but without communicating the error to the app, we have no way of knowing what is the most sensible course for recovery, so for EX we blindly restart not knowing if that will fix the issue or not.