Unhandled WebSocketConnectionClosedException

[h4nsu]

Occasionally this line:

py-substrate-interface/substrateinterface/base.py

Line 329 in 84485c1

self.__rpc_message_queue.append(json.loads(self.websocket.recv()))

blows up with WebSocketConnectionClosedException. Would it be ok to wrap it with an auto-reconnect try-catch just like here:

py-substrate-interface/substrateinterface/base.py

Lines 271 to 282 in 84485c1

	try:
	self.websocket.send(json.dumps(payload))
	except WebSocketConnectionClosedException:
	if self.config.get('auto_reconnect') and self.url:
	# Try to reconnect websocket and retry rpc_request
	self.debug_message("Connection Closed; Trying to reconnecting...")
	self.connect_websocket()
	return self.rpc_request(method=method, params=params, result_handler=result_handler)
	else:
	# websocket connection is externally created, re-raise exception
	raise

[arjanz]

Yes handling this in the application is the preferred way. There is an 'auto_reconnect' feature built in (auto_reconnect=True during init), which will work as well, but will hide side-effects like subscriptions being reset from the application.

[h4nsu]

Sorry, what I wrote was confusing. Here's what I meant:

This:

py-substrate-interface/substrateinterface/base.py

Line 272 in 84485c1

self.websocket.send(json.dumps(payload))

is wrapped with a try-block and handles broken sockets transparently when auto_reconnect=True.

Shouldn't the same practice be applied here:

py-substrate-interface/substrateinterface/base.py

Line 329 in 84485c1

self.__rpc_message_queue.append(json.loads(self.websocket.recv()))

so that I don't need to reconnect manually in my application and I can simply rely on auto_reconnect doing what it promises? ;)

[arjanz]

Ah I see what you mean now.. You are most likely right, now probably in case of a subscription with a long interval between responses the connection could be closed. The question is what will happen if during an active subscription the result_handler and its update_nr will be reset, I'll have to test if there are undesired side-effects.

If there aren't any I can just expand the try/catch and I'll link a PR, otherwise I think it's best to move to checks to the application, so there is more control what to do with these edge cases.