Finding
Both download-dispatch paths build an ergasia::DownloadRequest with protocol: ergasia::DownloadProtocol::Torrent hardcoded, discarding the queue item's actual DownloadProtocol. The queue/active entry carries a correctly typed protocol (Torrent or Usenet) stored from the indexer search result, but it is ignored at dispatch time, so every download — including NZB/Usenet items — is sent to the engine as a torrent. The defect is duplicated across the queued path (try_dispatch_next) and the interactive priority-4 bypass path inside enqueue.
Evidence
crates/syntaxis/src/lib.rs:357 (try_dispatch_next):
protocol: ergasia::DownloadProtocol::Torrent,
queue_item.protocol is in scope here (it is stored into ActiveEntry at line 333) but is never read.
crates/syntaxis/src/lib.rs:428 (interactive-bypass tokio::spawn in enqueue):
protocol: ergasia::DownloadProtocol::Torrent,
item.protocol is moved into the closure but is not referenced.
Why this matters
The entire Usenet acquisition path is dead: a Usenet item is handed to the engine as a torrent, invoking the wrong client and mis-parsing the download URL. Under the threat model this is worse than a functional bug — a download intended for a TLS-only Usenet provider is instead announced to a BitTorrent tracker and peer swarm, leaking acquisition intent and the node's address to network observers and to every peer in the swarm. Because the bug is duplicated, fixing one site silently leaves the other exploitable.
Desired correction
Convert the queue item's syntaxis::DownloadProtocol to ergasia::DownloadProtocol via a single From impl (or shared helper) and use it in both DownloadRequest constructions, so the conversion is single-sourced and cannot drift between the two paths. Done when: a Usenet queue item dispatches to ergasia with protocol = Usenet through both the queued (try_dispatch_next) and interactive paths.
Finding
Both download-dispatch paths build an
ergasia::DownloadRequestwithprotocol: ergasia::DownloadProtocol::Torrenthardcoded, discarding the queue item's actualDownloadProtocol. The queue/active entry carries a correctly typed protocol (Torrent or Usenet) stored from the indexer search result, but it is ignored at dispatch time, so every download — including NZB/Usenet items — is sent to the engine as a torrent. The defect is duplicated across the queued path (try_dispatch_next) and the interactive priority-4 bypass path insideenqueue.Evidence
crates/syntaxis/src/lib.rs:357(try_dispatch_next):queue_item.protocolis in scope here (it is stored intoActiveEntryat line 333) but is never read.crates/syntaxis/src/lib.rs:428(interactive-bypasstokio::spawninenqueue):item.protocolis moved into the closure but is not referenced.Why this matters
The entire Usenet acquisition path is dead: a Usenet item is handed to the engine as a torrent, invoking the wrong client and mis-parsing the download URL. Under the threat model this is worse than a functional bug — a download intended for a TLS-only Usenet provider is instead announced to a BitTorrent tracker and peer swarm, leaking acquisition intent and the node's address to network observers and to every peer in the swarm. Because the bug is duplicated, fixing one site silently leaves the other exploitable.
Desired correction
Convert the queue item's
syntaxis::DownloadProtocoltoergasia::DownloadProtocolvia a singleFromimpl (or shared helper) and use it in bothDownloadRequestconstructions, so the conversion is single-sourced and cannot drift between the two paths. Done when: a Usenet queue item dispatches to ergasia withprotocol = Usenetthrough both the queued (try_dispatch_next) and interactive paths.