chore(deps): bump elixir_torrent from 0.6.6 to 0.6.7

[dependabot]

Bumps elixir_torrent from 0.6.6 to 0.6.7.

Release notes

Sourced from elixir_torrent's releases.

0.6.7

A measurement release: six cases where the engine misbehaved and its own instruments read normal. Each was a local mistake counted as a network verdict and fed back into a control loop.

Fixed

• A tracker whose hostname stops resolving is dropped for the session instead of announced to forever — hackney raises :badarg rather than returning :nxdomain, so the failure carried no retry_in
• Announce failures now name the torrent and the announce URL, and classify hackney's wrapped connect timeout and HTTP 4xx/5xx
• :add_peer_failed no longer counts as a peer being unreachable — it is a local supervisor fault raised after a successful handshake, and it was depressing the per-family dial throttle
• The download speed readout no longer reports 0 B/s on a moving torrent: downloaded only advances per verified piece, so it is now averaged over a 60 s window
• A packed values string in a get_peers response is no longer misread as an IPv6 peer (18 is a multiple of 6); per BEP 32 the transport family now decides
• A disk error serving a BEP 52 hash request returns {:error, term()} instead of raising MatchError mid-function

Changed

• HTTP stack behind tracker announces and BEP 19 web seeds: hackney 4.7.4, h2 0.12.0, webtransport 0.4.5, quic 1.8.2

---

Install via Hex: {:elixir_torrent, "~> 0.6.7"} · requires Elixir ~> 1.20 · changelog · docs · full diff

Changelog

Sourced from elixir_torrent's changelog.

0.6.7 - 2026-09-14

A measurement release. Every fix here is a case where the engine was doing something wrong and the instruments said it was fine — a tracker retried forever because its failure had no reason attached, healthy peers marked unreachable because a local error was counted as a network one, and a download speed of 0 B/s reported on a torrent moving at 100 KB/s.

Fixed

• A tracker whose hostname no longer resolves is dropped for the session instead of being announced to forever. Hackney raises :badarg out of its connect path for a name with no A and no AAAA record rather than returning :nxdomain, so the HTTP announce returned a reason with no retry_in and got the default retry interval — tracker.openbittorrent.com, defunct, was re-announced six times an hour across four torrents. The UDP side never had this problem because it resolves up front and answers retry_in: "never". The :badarg catch now resolves the host itself and only writes a tracker off when DNS genuinely has nothing; other sources of :badarg keep the old opaque reason, because a permanent disable is too destructive to apply on a guess.
• Announce failures name the torrent and the announce URL. The line read request failure reason: <term> with neither, which made the most actionable message in the log useless: a tracker's own bencoded failure reason asks the user to re-add a torrent it never identified. Two classification gaps went with it — HTTPoison surfaces hackney's connect timeout as {:timeout, {:gen_statem, :call, [pid, :connect, 8000]}}, which the connect-timeout case never matched (42 of 89 warnings in a 21-minute window), and HTTP 4xx/5xx was not classified at all even though a 403 or 521 from a public announce-list entry is a dead tracker that BEP 12 already fails over.
• :add_peer_failed no longer counts as a peer being unreachable. It is emitted only after TCP connect and the full BEP 3 handshake succeed — we already hold the peer's id — and means the supervisor could not start, which is a local fault. It was depressing the measured per-family dial yield that drives the address-family throttle and writing DialBackoff rows toward the hard-fail threshold: one torrent held 61 of its 62 known endpoints sticky-blocked while connected to 4 peers. The catch-all also hid the outcome behind it — peer supervisors register under {peer_id, hash}, so a farm handing one id out from many IPs loses the race at start_child, which is :already_connected.
• The download speed readout no longer reports 0 B/s on a moving torrent. Torrent.Model differenced downloaded over its 5 s tick, but that counter advances only when a whole piece verifies, so the sample was quantized to piece size: at 55 KB/s with 1 MiB pieces three ticks in four read exactly 0.0. Two live torrents reported 0 B/s while gaining a combined 196 KB/s, and the ETA derived from it was :infinity throughout. The rate is now averaged over a 60 s window, held while a window containing progress matures, and clamped by piece_length / elapsed only when nothing has arrived at all. A torrent with nothing completed for 10 minutes reports 0. This is an improvement, not a cure: the source is still piece-granular, so a swarm delivering in bursts still oscillates, and a torrent slower than one piece per window reads 0 until its first piece lands.

... (truncated)

Commits

• 504fd34 chore: date 0.6.7 for the day it is actually released
• e60fb58 fix(dht): decide a values peer's family by transport, not by blob length
• 1fe7f55 ci(deps): bump github/codeql-action/upload-sarif
• 4964bc4 fix(bep52): return an error from a failed leaf read instead of raising
• 067e503 chore: release 0.6.7
• b6daf62 test(dht): compare against one routing table instead of building two
• 5ae434e fix(stats): average the download rate over a window, not one quantized sample
• 61eaefc fix(tracker): disable a DNS-dead HTTP tracker instead of retrying it forever
• 78b2cd1 fix(tracker): carry the term when a tracker task returns something unmatched
• cdee66e fix(tracker): name the torrent and tracker in announce failures
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!