pmtiles-swarm 0.24.2 → 0.24.4

package/CHANGELOG.md

@@ -7,6 +7,42 @@
 ### 🐞 Bug fixes
 - _...Add new stuff here..._
 
+## 0.24.4
+### 🐞 Bug fixes
+- **The feed advertised a .torrent nobody could fetch.** Every item named
+  `/api/torrents/<infohash>/file`, and that address is unreachable to exactly the audience a feed
+  is written for: the API is not on the public listener, so it answers 404 there, and on the
+  console listener it answers 401. Our own subscriptions got one or the other, and so did any
+  ordinary torrent client pointed at the same URL.
+
+  It failed quietly, which is why it lasted. `subscriptions.js` falls back to the magnet and logs a
+  line about it, so a mirror still joined and still downloaded. What the fallback costs is not
+  visible from there: BEP 9 carries only the info dict, and a v2 torrent's piece layers live
+  outside it, so an archive joined by magnet can never obtain them. On a hybrid torrent the mirror
+  then holds metadata it cannot verify pieces against and republishes a .torrent that claims v2
+  while omitting the hashes — 413 KB against the origin's 1,074 KB, the difference being precisely
+  20,636 pieces x 32 bytes. Anything mirroring from that mirror inherits it.
+
+  Items now name `/archives/<infohash>/archive.torrent`, which is public, unauthenticated, and the
+  same URL the TileJSON has always given for the same archive. Those two disagreeing was the bug;
+  a test now pins that they agree and that what they name answers 200 on the public surface.
+
+## 0.24.3
+### 🐞 Bug fixes
+- **Takes pmtiles-torrent 0.4.6.** Two things a node reading pieces on demand wanted. The sidecar
+  no longer discards the alerts that explain a failed read — `torrent_error_alert` and
+  `file_error_alert` were drained from the queue and thrown away by the one loop running while a
+  read was outstanding, so a full disk, an unwritable save path and a torrent that could not verify
+  its pieces all arrived as the same silent timeout. And the last piece of an archive is now
+  fetched before any header has been read: everything else is prioritised from the header, so until
+  one can be read nothing points anywhere but at the header, and planetiler writes the JSON
+  metadata and the leaf directories after all the tile data — where a partial mirror is least
+  likely to have them.
+
+  The floor is raised in the lockfile as well as the range. `^0.4.5` already permitted 0.4.6, and a
+  deployment installs from the lockfile, so without moving it `npm ci` would have gone on fetching
+  the version without either fix.
+
 ## 0.24.2
 ### 🐞 Bug fixes
 - **An empty `publicUrl` was read as an empty base rather than as no setting.** `??` treats only

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pmtiles-swarm",
-  "version": "0.24.2",
+  "version": "0.24.4",
   "description": "BitTorrent distribution for PMTiles map archives: create torrents, watch folders, publish and subscribe to RSS feeds, and seed through qBittorrent or an embedded client",
   "type": "module",
   "main": "src/index.js",
@@ -46,7 +46,7 @@
     "maplibre-gl": "^6.2.0",
     "parse-torrent": "^11.0.24",
     "pmtiles": "^4.4.1",
-    "pmtiles-torrent": "^0.4.5",
+    "pmtiles-torrent": "^0.4.6",
     "webtorrent": "^3.0.21"
   },
   "engines": {

package/src/feed.js

@@ -84,7 +84,27 @@ ${items}
  * @returns {string} - The item XML.
  */
 function renderItem(entry, baseUrl) {
-  const torrentUrl = `${baseUrl}/api/torrents/${entry.infoHash}/file`;
+  // The public route, which is the only one a subscriber can use.
+  //
+  // This named /api/torrents/<hash>/file, and that address is unreachable to
+  // everyone the feed is written for: the API is not on the public listener at
+  // all, so it answers 404 there, and on the console listener it answers 401.
+  // A feed is a public document whose whole purpose is to be followed by
+  // somebody else, and every consumer of it -- our own subscriptions, and any
+  // ordinary torrent client pointed at the same URL -- got one of those two.
+  //
+  // Nothing broke loudly, because subscriptions.js falls back to the magnet and
+  // logs a line about it. What that fallback costs is invisible from here and
+  // considerable: BEP 9 carries only the info dict, and a v2 torrent's piece
+  // layers live outside it, so an archive joined by magnet can never obtain
+  // them. On a hybrid torrent the mirror then holds metadata it cannot verify
+  // pieces against, and republishes a .torrent that claims v2 and omits the
+  // hashes -- measured at 413 KB against the origin's 1,074 KB, the difference
+  // being exactly 20,636 pieces x 32 bytes.
+  //
+  // Kept identical to what the TileJSON advertises for the same archive, in
+  // api.js. Those two disagreeing is what this was.
+  const torrentUrl = `${baseUrl}/archives/${entry.infoHash}/archive.torrent`;
   const map = entry.pmtiles;
 
   const mapFields = map