Patch for Tracker API response is not working #391
Description
The tracker API return a 200 HTTP status code when you try to get info for torrents that do not exist.
Tracker API endpoint: GET /api/torrent/:info_hash
The response is a 200 with this text body: torrent not known.
It's planned to fix it in the Tracker in the next API release.
The Index uses that endpoint to get the torrent statistics here:
pub async fn import_torrent_statistics(&self, torrent_id: i64, info_hash: &str) -> Result<TorrentInfo, ServiceError> {
if let Ok(torrent_info) = self.tracker_service.get_torrent_info(info_hash).await {
drop(
self.database
.update_tracker_info(torrent_id, &self.tracker_url, torrent_info.seeders, torrent_info.leechers)
.await,
);
Ok(torrent_info)
} else {
drop(self.database.update_tracker_info(torrent_id, &self.tracker_url, 0, 0).await);
Err(ServiceError::TorrentNotFound)
}
}We added a patch to the tracker service to return a not found error when we receive this response:
pub async fn get_torrent_info(&self, info_hash: &str) -> Result<TorrentInfo, ServiceError> {
let response = self
.api_client
.get_torrent_info(info_hash)
.await
.map_err(|_| ServiceError::InternalServerError)?;
if response.status() == StatusCode::NOT_FOUND {
return Err(ServiceError::TorrentNotFound);
}
let body = response.text().await;
if let Ok(body) = body {
if body == *"torrent not known" {
// todo: temporary fix. the service should return a 404 (StatusCode::NOT_FOUND).
return Err(ServiceError::TorrentNotFound);
}
let torrent_info = serde_json::from_str(&body);
if let Ok(torrent_info) = torrent_info {
Ok(torrent_info)
} else {
error!("Failed to parse torrent info from tracker response. Body: {}", body);
Err(ServiceError::InternalServerError)
}
} else {
error!("Tracker API response without body");
Err(ServiceError::InternalServerError)
}
}The patch is not working because I still get errors in the log:
2023-11-15T13:22:29.206201413+00:00 [torrust_index::tracker::service][ERROR] Failed to parse torrent info from tracker response. Body: "torrent not known"
This is not critical. It only pollutes the log with false errors. We also have a lot of false errors from SQLx. We should clean all of them. A log full of false errors is worse than no log and useless because you do not see legitimate errors.