During some thorough testing, I have discovered that when HTTP 429 status codes are returned to the client by Alpaca's Trading API, this client library code will attempt to retry by default. However in the process of doing so, the response body from from the previous attempt is not closed properly. This causes errors to be produced with the following message:
Post "https://paper-api.alpaca.markets/v2/orders": http: ContentLength=446 with Body length 0
This appears to happen because resp.Body.Close() is only called inside the verify() function, which is called only once and not once per c.httpClient.Do(req).
In my particular situation this is a simple fix now that I know the issue exists. Since retrying is something my code needs to handle explicitly, I decided to simply disable the client.RetryLimit by setting it to 0. Curiously though, client.RetryLimit cannot be set to 0, as it will be overwritten to become 3, as per https://github.com/alpacahq/alpaca-trade-api-go/blob/73c6e7be9314b272cc31b480bf67e12f7466e078/alpaca/rest.go#L59-L62 I am not positive why this is set this way, so consider this to be a second observation reported in this git issue. My response was to instead set RetryLimit = -1, which does produce the desired result of disabling retries.
So two issues:
Unnecessary error logging is printed on HTTP 429 responses, and
During some thorough testing, I have discovered that when HTTP 429 status codes are returned to the client by Alpaca's Trading API, this client library code will attempt to retry by default. However in the process of doing so, the response body from from the previous attempt is not closed properly. This causes errors to be produced with the following message:
This appears to happen because
resp.Body.Close()
is only called inside theverify()
function, which is called only once and not once perc.httpClient.Do(req)
.In my particular situation this is a simple fix now that I know the issue exists. Since retrying is something my code needs to handle explicitly, I decided to simply disable the
client.RetryLimit
by setting it to 0. Curiously though,client.RetryLimit
cannot be set to 0, as it will be overwritten to become 3, as per https://github.com/alpacahq/alpaca-trade-api-go/blob/73c6e7be9314b272cc31b480bf67e12f7466e078/alpaca/rest.go#L59-L62 I am not positive why this is set this way, so consider this to be a second observation reported in this git issue. My response was to instead setRetryLimit = -1
, which does produce the desired result of disabling retries.So two issues:
Thanks!