src/tracker/impls/torrent_tracker_handlers.rs (2)

244-269: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Don't enqueue a zeroed torrent update for a no-op stopped announce.

The wildcard arm on Line 263 collapses “peer/torrent not found” and “torrent removed entirely” into the same AnnounceEntry::default(), and the unconditional add_torrent_update right after that writes zeros in both cases. A repeated or bogus stopped request can therefore create or overwrite a zero-count cache/DB record for an info hash that was never present.

Suggested fix

-                let torrent_entry = match data.remove_torrent_peer(
+                let (torrent_entry, should_update) = match data.remove_torrent_peer(
                     announce_query.info_hash,
                     announce_query.peer_id,
                     is_persistent,
                     false
                 ) {
-                    (Some(_), Some(new_torrent)) => {
+                    (Some(_), Some(new_torrent)) => {
                         if users_enabled && let Some(user_id) = user_key && let Some(mut user) = data.get_user(user_id) {
                             user.uploaded += announce_query.uploaded;
                             user.downloaded += announce_query.downloaded;
                             user.updated = SystemTime::now().duration_since(SystemTime::UNIX_EPOCH).unwrap().as_secs();
                             user.torrents_active.remove(&announce_query.info_hash);
                             data.add_user(user_id, user.clone());
                             if is_users_persistent {
                                 data.add_user_update(user_id, user, UpdatesAction::Add);
                             }
                         }
-                        new_torrent
+                        (new_torrent, true)
                     }
-                    _ => AnnounceEntry::default()
+                    (Some(_), None) => (AnnounceEntry::default(), true),
+                    _ => (AnnounceEntry::default(), false),
                 };
-                if needs_update {
+                if needs_update && should_update {
                     let _ = data.add_torrent_update(
                         announce_query.info_hash,
                         TorrentUpdateData::from(&torrent_entry),
                         UpdatesAction::Add
                     );

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/tracker/impls/torrent_tracker_handlers.rs` around lines 244 - 269, The
code unconditionally enqueues a zeroed TorrentUpdate when remove_torrent_peer
falls through to AnnounceEntry::default(), causing bogus zeroed records on no-op
stopped announces; change the logic around the match on data.remove_torrent_peer
(the branch that currently returns AnnounceEntry::default()) to detect the “not
found / no-op stopped” case and skip calling data.add_torrent_update when there
is no real torrent to update (i.e., only call data.add_torrent_update when the
match yields Some(new_torrent) or when torrent_entry represents a real torrent
state change), using announce_query.stopped or announce_query.event to
distinguish stop no-ops from genuine removals and preserving the existing
needs_update behavior otherwise.

---

291-315: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Use needs_update in the completed path as well.

Started and Stopped both propagate TorrentUpdateData when persistence or cache is enabled, but Completed only does so when is_persistent is true. In cache-only deployments that drops completed/count updates entirely until some later announce touches the torrent.

Suggested fix

-                    if is_persistent {
+                    if needs_update {
                         let _ = data.add_torrent_update(
                             announce_query.info_hash,
                             TorrentUpdateData::from(&rtc_entry),
                             UpdatesAction::Add
                         );
                     }
@@
-                    if is_persistent {
+                    if needs_update {
                         let _ = data.add_torrent_update(
                             announce_query.info_hash,
                             TorrentUpdateData::from(&torrent_entry),
                             UpdatesAction::Add
                         );
                     }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/tracker/impls/torrent_tracker_handlers.rs` around lines 291 - 315, The
completed branch only writes TorrentUpdateData when is_persistent is true;
change those guards to include the cache-update flag by using needs_update (e.g.
if needs_update || is_persistent { ... }) for the torrent update (the
add_torrent_update call using TorrentUpdateData::from(&rtc_entry)) and similarly
include needs_update when deciding to call data.add_user_update for the user
update (e.g. if is_users_persistent || needs_update { ... }). Ensure you update
both the completed-path checks so cache-only deployments also propagate the
completed/count updates.

src/database/impls/database_connector_mysql.rs (1)

246-253: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Persist total seed/peer counts here, not just the IPv4 buckets.

column_seeds and column_peers are the only persisted counters for a torrent, but this now writes counts.seeds_ipv4 / counts.peers_ipv4 directly. Any IPv6 or RTC peers disappear from the stored totals, so scrape data and post-restart state will undercount after a sync. The same regression is repeated in the PgSQL and SQLite save_torrents implementations in this PR.

Also applies to: 280-287

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/database/impls/database_connector_mysql.rs` around lines 246 - 253, The
code is persisting only IPv4 buckets (counts.seeds_ipv4/counts.peers_ipv4) into
the aggregate columns; change the upsert to write the total seed/peer counters
instead (use the overall counters on the counts struct, e.g. counts.seeds and
counts.peers or counts.seeds_total/counts.peers_total as available) when calling
build_upsert_torrent_query for &structure.column_seeds and
&structure.column_peers; make the identical change in the save_torrents
implementations for PgSQL and SQLite so the persisted totals include IPv6/RTC
counts as well.

src/tracker/impls/torrent_tracker_peers.rs (1)

141-150: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Remove the previous peer from both IP-family maps before re-inserting.

This replacement path only deletes the old entry from the incoming peer's current family. If the same peer_id re-announces on IPv6 after previously existing on IPv4 (or the reverse), the stale entry survives in the old map and then a second entry is inserted into the new map, which inflates both peer lists and stats.

Suggested fix

-                let (seeds_removed, peers_removed) = if torrent_peer.peer_addr.is_ipv4() {
-                    (
-                        i64::from(entry.seeds.remove(&peer_id).is_some()),
-                        i64::from(entry.peers.remove(&peer_id).is_some()),
-                    )
-                } else {
-                    (
-                        i64::from(entry.seeds_ipv6.remove(&peer_id).is_some()),
-                        i64::from(entry.peers_ipv6.remove(&peer_id).is_some()),
-                    )
-                };
+                let seeds_removed = i64::from(entry.seeds.remove(&peer_id).is_some())
+                    + i64::from(entry.seeds_ipv6.remove(&peer_id).is_some());
+                let peers_removed = i64::from(entry.peers.remove(&peer_id).is_some())
+                    + i64::from(entry.peers_ipv6.remove(&peer_id).is_some());

Also applies to: 193-206

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/tracker/impls/torrent_tracker_peers.rs` around lines 141 - 150, The code
only removes the peer_id from the IP-family matching the incoming announce,
leaving a stale entry in the opposite family; change the logic so you remove
peer_id from both IPv4 and IPv6 maps before inserting the new record: call
entry.seeds.remove(&peer_id), entry.peers.remove(&peer_id),
entry.seeds_ipv6.remove(&peer_id) and entry.peers_ipv6.remove(&peer_id) (or
perform a small helper like remove_peer_from_all_families(peer_id, &mut entry))
and then compute seeds_removed/peers_removed based on whether any of the removes
returned true; apply the same fix to both places where this branch logic appears
(the blocks handling removal/re-insert around torrent_peer and peer_id).