Sorry, we don't support your browser.  Install a modern browser

Websocket + GraphQL candles subscription first response is from an old timestamp#24

Z

On subscribing to candles using GraphQL and websocket, the first response is from an old timestamp. Specifically, from the timestamp of the last response received before closing the last websocket.

For Example:

Using the query:
subscription candles(
marketId: “<marketID>“,
interval: I1M
) timestamp
datetime
open
high
low
close
volume
interval
}
}

Response/message 1:
“candles”: “timestamp”: “1601258460000000000”,
“datetime”: “2020-09-28T02:01:00Z”,
“open”: “127351”,
“high”: “127361”,
“low”: “127339”,
“close”: “127361”,
“volume”: “536099”,
“interval”: “I1M”
}

message 2:
“candles”: “timestamp”: “1601258640000000000”,
“datetime”: “2020-09-28T02:04:00Z”,
“open”: “127343”,
“high”: “127412”,
“low”: “127343”,
“close”: “127386”,
“volume”: “514192”,
“interval”: “I1M”
}

message 3:
“candles”: “timestamp”: “1601258640000000000”,
“datetime”: “2020-09-28T02:04:00Z”,
“open”: “127343”,
“high”: “127412”,
“low”: “127343”,
“close”: “127386”,
“volume”: “537959”,
“interval”: “I1M”
}

See the datetime for response 1 is from a few minutes before - consistently the datetime of the last message received before I closed my last websocket.

I thought it might be a local caching issue, but I get the same results when subscribing from a new computer, using a different ip (my phone as a hotspot). It’s also consistent across the playground and my node app.

It seems like it must be coming from the server side!?

It’s not a big deal (I’ve just coded to drop the first candle response) but thought I’d mention to you guys.

2 months ago
1

Thanks Zach, I’ve raised a ticket for that, and we’ll get back to you when someone looks into it.

2 months ago