You're viewing a single thread.
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?
It should display a human-readable error message instead of the raw one.
Take it as an error, tell the user about it and then retry with exponential back-off.
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.
You really shouldn't be expecting any content type when you get any code but a 200. If anything you should expect HTML, then, possibly plain text but that's a subset (given a loose enough definition of html).
If it's Jerboa/Android app issue, why do I get JSON errors using Lemmy on my desktop PC with Firefox? Forgive me if this is a dumb question, I have very little programming knowledge.
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.
lemmy does not return 502 error codes because 502 means "bad gateway" and lemmy is not acting as a gateway, nginx is. An nginx sends the html. All apps should check the status code for codes like this one that don't come from apps.
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.
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
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
just adding retries can makes the problem.even worse with the app ddosing the server
Twitter has some experience with that
true
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.
When you get a 502 error, that's not coming from lemmy, it's coming from nginx. If you're saying that nginx should send any error data along with the status in json if the accept headers require it, that's a task for nginx but it wouldn't happen in this case anyway since the json wouldn't be what they were expecting anyway. The app should be handling non success responses better is the point being made here.
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.
The error is not being emitted by Lemmy though. The 502 error message is returned to the client by nginx when the Lemmy server doesn't respond within the a certain time.
[This comment has been deleted by an automated system]
Yeah this makes more sense than my original comment
Definitely jerboa
I'm having similar errors using liftoff
I'm having similar errors using liftoff