Unhandled promise rejection when calling the stopOrder function

Question

Unhandled promise rejection when calling the stopOrder function

Closed this issue 7 years ago · 11 comments

JustinNothling commented 7 years ago

UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: BitX error 504

Any ideas?

andrewrobertdavies commented 7 years ago

Thanks

Answer 1 · 2017-05-08T06:16:32.000Z

This module doesn't use promises so that part must be coming from your code, but the error is caused by an HTTP response status code of 504 (Gateway Timeout) being returned by the Luno API. Their docs don't mention a case where a 504 would be returned so I can only suspect that the issue is on the Luno side. I'm able to access their API at the moment, so maybe try again now?

Answer 2 · 2017-05-08T09:10:51.000Z

Afraid I'm still getting the same 504 timeout error. Are you able to call stopOrder as part of a series of calls? stopOrder works correctly for me if it is the only call but produces the error when there are more processes happening after it.

Answer 3 · 2017-06-13T06:50:39.000Z

When I just call any of the GET methods via this library all works fine -- both for single calls and consecutive calls.
Similarly, when I just call any of the POST methods via the library all works fine -- both for single calls and consecutive calls.
However, if I call a POST method followed by a GET method then I get the above 504 error and the GET request http request never ends
Subsequent POST calls still work but not GET
the GET requests are only handled again once I restart my server

As a check, I have run sequences similar to the above using curl and the issues do not occur.

Answer 4 · 2017-06-13T07:28:41.000Z

@andrewrobertdavies Thanks for the additional detail. I will try and find some time to investigate this further in the next few days and keep you updated.

Answer 5 · 2017-06-13T09:19:33.000Z

Additionally: I am performing similar operations re: the Bitstamp exchange using the npm Bitstamp lib (which appears to be a very similar https wrapper) but the problems above are not encountered.
Possibly related to the Rate Limiting per the Luno documentation & the node https handling of sockets?

Answer 6 · 2017-06-13T09:26:15.000Z

@bausmeier it appears to be working now so I think the issue must have been with luno and not your library.

Answer 7 · 2017-06-13T10:02:34.000Z

Ok - so here is what is happening & it is on the Luno server end.

The 'rate limiting' allows 'bursts up to 5 consecutive calls'.
Calls by all methods count towards this tally.
Once the tally reaches 5 GET calls become blocked, but POST calls do not.

This approach kind of makes sense in maintaining the ability to trade but preventing data being drawn from the server unconditionally.

The blocking gets lifted after a period of a few minutes.

Again though, calling via curl (or resetting the client server) circumnavigates this issue so it is something to do with the sockets/connections when called by the node https methods.

Answer 8 · 2017-06-13T10:15:30.000Z

Thanks for investigating further. I think there is an issue in this package to do with the headers that are being set when a post request is sent. I will confirm and fix it this evening.

Answer 9 · 2017-06-13T15:41:28.000Z

I published bitx@1.5.1. Please confirm that this resolves your issue.

The API does do rate limiting, but returns the correct 429 Too Many Requests response code in that case. The 504 that you were getting was because the content type and content length headers from the previous POST request were being included in following GET requests and it seems like the gateway timeout was due to the server waiting for the content to arrive. I implemented a fix so that these headers are no longer included incorrectly on the GET requests.

Answer 10 · 2017-06-13T16:41:08.000Z

Works like a charm. Thanks!