Stream data not udpated after got event "listenKeyExpired" #275
Comments
|
Got another listenKeyExpired event just now, it lasts less than 5 hours this time. |
|
Can you provide a DEBUG log of ubwa please? |
|
Here it is:
This time it lives over 10+ hours... Please pay attention to the line with timestamp: 2022-06-01 12:10:51,641, it received inner asyncio.TimeoutError, and then got listenKeyExpired event at 2022-06-01 12:10:52,144. Please let me know if need more information. |
|
Checked the logs again, the "Received inner asyncio.TimeoutError" occurred not only right before listenKeyExpired event, it appears in lots of place even in several hours before got that event. |
|
Recently I'm still frequently got listenKeyExpired event, and I changed the code to call create_stream() again after got that event. Meanwhile, it might send two listenKeyExpired events at almost same time, you should avoid to call create_stream() twice in that time. Looks good in last whole week. |
|
@oliver-zehentleitner Any ideas? |
|
Hello Oliver, Regards |
|
LUCIT-Systems-and-Development/unicorn-fy#41 |
Just FYI, I added some code like below, it works well in last month, you can base it to get your own version: elif event_type == "listenKeyExpired":
listen_key_expired_timestamp = datetime.fromtimestamp(stream_data['E'] / 1000)
self.logger.warning(f"Listen key expired at {listen_key_expired_timestamp}: {stream_data}")
if self.listen_key_expired_timestamp is None \
or listen_key_expired_timestamp - self.listen_key_expired_timestamp > timedelta(seconds=10):
# Never expired or last expired time is 10 seconds ago
self.listen_key_expired_timestamp = listen_key_expired_timestamp
self.bw_api_manager.create_stream(
["arr"], ["!userData"], api_key=self.config.BINANCE_API_KEY, api_secret=self.config.BINANCE_API_SECRET_KEY
)
else:
self.logger.warning(f"WARN: Not handled 'e' event: {stream_data}") |
@bobwng what will happen if, for example, an order is filled on the exchange before the creation, or at the time of the stream creation. the message is lost? |
Hello diva, in my experience the message is lost and all hell starts to break lose on your bots :( Andre |
Hi Bob, |
Hi Bob, a question about your code: If I had previously started a thread to wait for messages. If I use a replace_stream will I need to stop the old thread and start a new one ? Thanks |
I have no experience on replace_stream, per comments mentioned in the sample code below, looks like no need to stop the old stream manually: unicorn-binance-websocket-api/example_stream_management.py Lines 68 to 69 in 010cb9d |
That's great! Just FYI that the lib should already have the keep alive related code, but not sure why it not works: unicorn-binance-websocket-api/unicorn_binance_websocket_api/manager.py Lines 691 to 692 in 010cb9d |
self.restclient.keepalive_listen_key(stream_id)
def keepalive_listen_key(self,
stream_id=False,
api_key=False,
api_secret=False,
listen_key=False,
last_static_ping_listen_key=False):
with self.threading_lock:
self._init_vars(stream_id, api_key, api_secret, listen_key, last_static_ping_listen_key)
return self._do_request("keepalive")
def _do_request(self, action=False):
if action == "keepalive":
logger.info(f"BinanceWebSocketApiRestclient.keepalive_listen_key({str(self.listen_key_output)})")
method = "put"
try:
response = self._request(method, self.path_userdata, False, {'listenKey': str(self.listen_key)})
self.last_static_ping_listen_key = time.time()
return responseVery strange logic |
Yes, and I don't think it works, sometimes when I launch the bot, the first message it receives is a listenKeyExpired !!! |
|
@oliver-zehentleitner @amdescombes @bobwng @dima-dmytruk23 code |
|
@netsesame what will happen if, for example, an order is filled on the exchange before the creation, or at the time of the stream creation. the message is lost? I see 2 solutions to the problem:
The first option is more reliable, in my opinion. |
|
Hi, I'm fighting the same issue here with the user data stream stopping after
So, when the second client deletes the listen key before exiting, the first client will no longer receive messages on that listen key. Binance will not disconnect the websocket - it will simply stop sending data. I tried calling |
|
Thanks for the good reports and analysis.
Thanks @hiliev
I set the interval from refreshing the If the problem persists, we can create a way to set the interval time manually. If necessary, the code for "keep alive" must be revised. |
|
lets continue here: #301 |
Version of this library.
unicorn_fy: 0.11.0
unicorn_binance_local_depth_cache: not found
unicorn_binance_rest_api: not found
unicorn_binance_trailing_stop_loss: not found
unicorn_binance_websocket_api: 1.41.0
Solution to Issue cannot be found in the documentation or other Issues and also occurs in the latest version of this library.
Hardware?
VPS or other cloud hosting
Operating System?
Linux
Python version?
Python3.8
Installed packages
Logging output
Processing method?
process_stream_data
Used endpoint?
binance.com-coin_futures
Issue
I subscribe both !userData and !miniTicker stream, !userData stopped to get new update after got listenKeyExpired event. But last time(2022-05-30 00:42:24,114) both userData/miniTicker are stopped to send update.
There is no significant error/warning logs like "time out", "connection interrupted" etc. No related code change in recent days, except adding some new log specific for listenKeyExpired event. And the scripts never prompt such information in recent months.
I found API "PUT /fapi/v1/listenKey" not exposed, not sure if we can expose this API and then I can invoke it manually to prevent this event?
The text was updated successfully, but these errors were encountered: