Skip to content

torrent lifecycle: duplicate torrent_id delete destroys sibling download #536

Description

@forkwright

Finding

torrent_map (line 223) lets two DownloadIds map to the same librqbit torrent_id when add_torrent returns AlreadyManaged for a duplicate info-hash, and delete_torrent unconditionally session.delete()s the shared id with no reference check — so deleting one download destroys the other's live torrent (get/stats/pause then return TorrentNotFound) until a restart reconcile prunes the stale entry; the add-path already flagged this hazard but guarded only its own failure branch.

Evidence

crates/ergasia/src/session.rs:223. Surfaced by the 2026-07-03 deep-audit workflow (adversarially verified + Opus-judged).

Why this matters

Deleting one download can destroy another download's live torrent data whenever two DownloadIds share a librqbit torrent_id, causing an unrelated download to silently fail until a restart reconciles it.

Desired correction

Reference-count or reverse-index torrent_ids: on delete, only call session.delete() when no other DownloadId still maps to that torrent_id; otherwise just drop the mapping entry. Optionally dedup by info-hash at enqueue time.

Done when: the defect's failure mode no longer reproduces and a regression test covers it.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions