🤔 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.
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.
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.
The server responded with an appropriate HTTP status code and an appropriate MIME type. If the JSON were malformed I’d agree that this is a client issue, but in this case the client failed to deal with the error states of the underlying transport correctly. It shouldn’t have even tried to parse text/html as application/json in the first place!
Is it a lemmy issue or a jerboa issue?
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.
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.
Well, what should Jerboa do? Pretend it received content?
Take it as an error, tell the user about it and then retry with exponential back-off.
It should display a human-readable error message instead of the raw one.
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.
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.
The server responded with an appropriate HTTP status code and an appropriate MIME type. If the JSON were malformed I’d agree that this is a client issue, but in this case the client failed to deal with the error states of the underlying transport correctly. It shouldn’t have even tried to parse text/html as application/json in the first place!
Yeah this makes more sense than my original comment