Datafeed: Common Issues
This article describes common issues that users face when they implement the Datafeed API. These issues are mostly related to the getBars
method. The library calls it to get historical data in a certain range.
getBars Is Called Multiple Times
The library calls getBars
multiple times if the amount of provided data is less than requested. To debug this issue, enable console logs. Consider the following example:
FEED [AAPL|1D]: Next time received: `2018-03-27T00:00:00.000Z`
FEED [AAPL|1D]: Processing pending subscribers, count=2
// The library requests 329 bars from the datafeed
FEED [AAPL|1D]: Leftmost subscriber requires 329 bars prior 2022-11-09T00:00:00.000Z
FEED [AAPL|1D]: Requesting data: [2016-12-22T00:00:00.000Z ... 2021-08-06T00:00:00.000Z, 329 bars]
// The datafeed responds with 157 bars
// 157 is less than requested, so the library will request the remaining bars from the datafeed
FEED [AAPL|1D]: Receiving bars: total 157 bars in [2017-08-10T00:00:00.000Z ... 2018-03-27T00:00:00.000Z], requested range: [2016-12-22T00:00:00.000Z ... 2021-08-06T00:00:00.000Z, 329 bars]
FEED [AAPL|1D]: Processing pending subscribers, count=2
// The library requests 172 bars from the datafeed
// It requests 172 bars because 329 - 157 = 172
FEED [AAPL|1D]: Leftmost subscriber requires 172 bars prior 2017-08-10T00:00:00.000Z
FEED [AAPL|1D]: Requesting data: [2016-04-26T00:00:00.000Z ... 2016-12-22T00:00:00.000Z, 172 bars]
// The datafeed responds with 169 bars
// 169 is less than requested, so the library will request the remaining bars from the datafeed
FEED [AAPL|1D]: Receiving bars: total 169 bars in [2016-04-26T00:00:00.000Z ... 2016-12-22T00:00:00.000Z], requested range: [2016-04-26T00:00:00.000Z ... 2016-12-22T00:00:00.000Z, 172 bars]
FEED [AAPL|1D]: Processing pending subscribers, count=2
// The library requests 3 bars from the datafeed
// It requests 3 bars because 172 - 169 = 3
FEED [AAPL|1D]: Leftmost subscriber requires 3 bars prior 2016-04-26T00:00:00.000Z
FEED [AAPL|1D]: Requesting data: [2016-04-23T00:00:00.000Z ... 2016-04-26T00:00:00.000Z, 3 bars]
// The datafeed responds with 2 bars
// 2 is less than requested, so the library will request the remaining bars from the datafeed
FEED [AAPL|1D]: Receiving bars: total 2 bars in [2016-04-25T00:00:00.000Z ... 2016-04-26T00:00:00.000Z], requested range: [2016-04-23T00:00:00.000Z ... 2016-04-26T00:00:00.000Z, 3 bars]
FEED [AAPL|1D]: Processing pending subscribers, count=2
// The library requests 2 bars from the datafeed
// Here the library actually requests 1 more bar than it requires, but that's OK and datafeed implementations should be able to handle it
FEED [AAPL|1D]: Leftmost subscriber requires 2 bars prior 2016-04-25T00:00:00.000Z
FEED [AAPL|1D]: Requesting data: [2016-04-21T00:00:00.000Z ... 2016-04-23T00:00:00.000Z, 2 bars]
FEED [AAPL|1D]: Receiving bars: total 2 bars in [2016-04-21T00:00:00.000Z ... 2016-04-22T00:00:00.000Z], requested range: [2016-04-21T00:00:00.000Z ... 2016-04-23T00:00:00.000Z, 2 bars]
FEED [AAPL|1D]: Processing pending subscribers, count=2
To avoid multiple getBars
requests, you can return bars before the from
date until their number matches the countBack
value. For example, the chart requests 300 bars in the range [2019-06-01T00:00:00…2020-01-01T00:00:00)
, and your backend has only 250 bars in the requested period. Return these 250 bars and 50 bars prior to 2019-06-01T00:00:00
.
Bar Data Is Mutable
The library may mutate the values of some Bar
objects that you provide. You can make a copy of your data to avoid potential issues.
Requested Data is Outside Visible Range
The [from, to)
range usually matches VisibleTimeRange
. However, sometimes the library requests more bars than are visible, because indicators require some additional history.