Fix torified bad requests
Closed this issue · 1 comments
Describe the bug
The coordinator replies with Error 4XX with body "bad_request":"reason" in many ocassion. At the moment, these requests work without problem in the Web client. The bad request reason is used to display elements to the user. However, on the torified webview Android App these requests "fail" the try/catch in . Therefore, there is no body response to parse, and the "reason" never makes it to the UI.
Here the response body is not returned in the reject() in act, torDaemon seem to not be fit to return the body if status is 400.
In addition, here the error is "lost" since the .catch() returns sendTorStatus instead of error.
To Reproduce
This issue can be observed everytime the coordinator replies with a 400 status. Example:
- Recover a robot with token the token
aaaaaaaaaaaaaa. You expect the coordinator to return with a 400, reason "Token does not have enough entropy", however, on the torified app the request to create a new robot never seems to finish. - Fetch an order book that is empty. The response is 400 "No orders". However the Android app seems to never finish fetching the book. Can be tested using the Testnet switch (as testnet usually never has active orders).
- Create an order then cancel it. The coordinator replies with a 400 "Maker cancelled the order" when you cannot access the order anymore. However it seems
Expected behavior
The android torified app should behave the same way as the Web Client.
Additional context
I have tried 3 different quick ways to solve this issue none of which work. Can be seen in branch https://github.com/Reckless-Satoshi/robosats/tree/fix-torified-bad-requests .
Another workaround is to never send a response that has a useful body with status.HTTP_400_BAD_REQUEST from the coordinator.
There is a chance this issue cannot be solved (maybe react-native-tor simply will never return the request body if status is 400). But if someone wants to dig into it, it is now rewarded with 400K Sats ⚡