Investigate suspect remote select response

[qstokkink]

The ContenDiscoveryCommunity disseminates TorrentsHealthPayload between peers. For all health info in such a message, the peer that sent the health info is queried for the full torrent metadata (using a select message).

TriblerExperimental/src/tribler/core/content_discovery/community.py

Lines 154 to 159 in 8e3ea79

	for health_info in health_list:
	# Get a single result per infohash to avoid duplicates
	with db_session:
	self.composition.metadata_store.process_torrent_health(health_info)
	infohash = hexlify(health_info.infohash).decode()
	self.send_remote_select(peer=peer, infohash=infohash, last=1)

These select queries are answered with SelectResponsePayload messages. However, the response result seems to always be an empty list (perhaps I just got unlucky?):

TriblerExperimental/src/tribler/core/content_discovery/community.py

Line 357 in 8e3ea79

self.logger.debug(f"Response result: {processing_results}")

We should investigate this matter. I might have gotten unlucky, this may be a bug¹, this may indicate that we should filter infohashes, or this may mean that we need to actively queue metadata retrieval. Perhaps all of the above.

Footnotes

1. Unlikely given the result of the unittest described below. ↩

[qstokkink]

I added a quick test to TestMetadataStore, I wanted to compare the underlying get_entries call to the threaded version that is used in the ContentDiscoveryCommunity. I'm not sure if this test is failing due to the unit test setup, or if this is a problem in practice. However, it is suspect. I assume we would've noticed if there was something this bad going on in the wild. The test was failing due to the self.metadata_store using :memory: instead of a "real" database file.

    async def test_bla(self):
        other_key = default_eccrypto.generate_key("curve25519")
        with db_session:
            self.metadata_store.TorrentMetadata(title="test torrent", infohash=b"\x01" * 20, id_=0, timestamp=0,
                                                torrent_date=int2time(0), public_key=other_key.key_to_bin())
        print("Non-threaded:", self.metadata_store.get_entries(infohash=b"\x01" * 20, last=1))
        print("Threaded:", await self.metadata_store.get_entries_threaded(infohash=b"\x01" * 20, last=1))

It seems that the basic functionality of get_entries_threaded is working correctly.

[qstokkink]

First unexpected behavior. The FakeDHTSession only gets created and doesn't seem to actually do anything.

TriblerExperimental/src/tribler/core/torrent_checker/torrent_checker.py

Lines 344 to 347 in 567c84e

	session = FakeDHTSession(self.download_manager, timeout)
	session.add_infohash(infohash)
	self._logger.info("DHT session has been created for %s: %s", infohash_hex, str(session))
	self.sessions["DHT"].append(session)

I added self.register_anonymous_task("FakeDHT resolve", session.connect_to_tracker) after this code to make it connect.