Weird response from Volley request
from the CommonsWare Community archivesAt February 27, 2019, 2:52pm, Raptor asked:
Hello,
I have an issue with a Volley request that on some phone returns a result, but on other phones returns a different result. I have no idea how this is possible.
It is a POST request that contains the following data:
{
“user_id” : “5c62d7d060rt64321ee60a53”,
“category” : “57gh4f66a1f8ae9c0e287ca0”,
“lat” : “54.40423071683623”,
“long” : “16.09879057854414”
}
This is supposed to return some data, but when the backend responds, it returns a different JSON, depending on the phone that I am using. If I do the same request from Postman, I get the correct response.
Do you have any ideas on how to approach this? (I’ve also replaced the obsolete Volley library from the app and used the latest version, but it acts the same exact way).
Thanks!
EDIT: If I put “user_id” as null, I get the same response (a list of 8 users) on the “faulty phone”, whereas on the “working phone” I get an error, as it should. How can that be? Also, if I don’t put any category key-value pair for the request, in Postman, I get the list of 8 users. The same happens in the faulty phones and in the working ones.
So basically, the faulty phone acts as if it’s making a correct request, with the required user_id and without a category key-value pair (and receives the list of 8 users), regardless of what you put in the body of the request. I actually deleted everything from the jsonParams, sending an empty body. The response from the backend was the same 8 elements, despite my request not having the required “user_id” key.
At February 27, 2019, 11:37pm, mmurphy replied:
I’d start by hooking up Charles Proxy (or the equivalent) and seeing what is different about the requests. Your symptoms make it seem like you will find that your faulty devices have the wrong POST body or something. If, OTOH, you see correct request bodies going out, perhaps there is something else that you will see in the requests. And, if you see that the responses from the server are correct in Charles but wrong in the app, then you’ll need to double-check what you are getting from Volley and how you are processing it.
Other than an obsolete book example, I have never used Volley. If you were using OkHttp, you could also use interceptors to try to understand what’s going on, and there’s a whole industry around OkHttp add-ons for debugging.
At February 28, 2019, 4:04pm, Raptor replied:
So, I installed Charles Proxy and tested a faulty phone. It would indeed launch a request to login, no problems (which works). But in the case of a request where there’s the problem, it doesn’t send any request whatsoever. It doesn’t appear in the list.
I then used my phone (which works correctly) that DOES send the request to the said endpoint.
How could this be? How could one phone send a request (and receive the correct data) and another “pretend to send the request” and “receive” phantom data?
At February 28, 2019, 4:39pm, mmurphy replied:
Sorry, I am out of the office for the rest of week, so please forgive me if this comes out poorly formatted…
I cannot explain your symptoms. Make sure that the affected devices are really invoking Volley and is not somehow relying upon some local cache.
MLM