Is it a lemmy issue or a jerboa issue?
I would say Lemmy issue. This is probably a default 502 internal sever error response (which I’ve been getting repeatedly from lemmy.world). Jerboa (I don’t use it btw) is only trying to parse the expected json response. Yes the app could handle the error more gracefully but if Lemmy didn’t respond with an error jerboa wouldn’t need to.
Lemmy realy should not randomly emit errors for no reason, there should be no need for retries in this case. If the specification specifies a JSON response, and the server randomly provides HTML, that is a bug in the server.
personally I’d say it’s a Jerboa thing. the app should retry loading because sometimes I refresh after this happening and it immediately loads the proper content.
with all the different instances this sort of thing has to be kept in mind
Lemmy realy should not randomly emit errors for no reason, there should be no need for retries in this case. If the specification specifies a JSON response, and the server randomly provides HTML, that is a bug in the server.
Just retry is usually a bad ideia, specially that this problem is probably an overload, just adding retries can makes the problem.even worse with the app ddosing the server
Serious Answer: This is a Jerboa issue. Lemmy is written in Rust. The error message is a Java error which is what native Android apps use.
No, this is a lemmy issue. The API specification specifies a JSON response, and the server randomly provides HTML, this is a bug in the server. I agree that Jebora should retry in the case of a network failure (timeout, 4xx staus codes…) but it should not have to retry in a case of a server that is not folowing the standard.
No, it’s probably when the app is expecting a json but the server returns an html, which usually happens in case of 502 errors.
I think it’s both, actually. Lemmy is often giving html where json is expected, and Jerboa isn’t handling the error well.
🤔 The server spits out html when it cannot reach the backend. So one could argue it’s a configuration issue because the admin didn’t provide enough capacity / didn’t set up a proper generic json error for backend failures.
FWIW, Liftoff doesn’t handle these super gracefully either.
At any rate I think it’s kinda awesome that we get to witness these kinds of infancy problems.