Transport: Not existing global room join is slow

[ulope]

Problem Definition

When Raiden tries to join a not yet existing global room it attempts to find this room on all known servers.

Requests with aliases that don't point to the current homeserver are federated.
Due to unknown reasons (possibly a bug in the increasingly outdated synapse version we're using, related #3387) those federation requests return an HTTP status of 500 instead of the correct 404. This leads to the retry mechanism in GMatrixHttpApi:

raiden/raiden/network/transport/matrix/client.py

Lines 148 to 155 in 2900c11

	for delay in self.retry_delay():
	try:
	with self._semaphore:
	return super()._send(method, path, *args, **kwargs)
	except (MatrixRequestError, MatrixHttpLibError) as ex:
	# from MatrixRequestError, retry only 5xx http errors
	if isinstance(ex, MatrixRequestError) and ex.code < 500:
	raise

delaying the bubbling up of the exception to the MatrixTransport where it signifies that the next server should be used.

Possible Solutions

• Possibly an update of the Synapse version will solve the 404/500 discrepancy and nothing is required to be done in Raiden
• Implement a way to suspend request retry during global room join

[ulope]

This is now obsolete since room creation is happening server side.

See raiden-network/raiden-service-bundle#47