pmtiles-swarm 0.35.3 → 0.35.5

package/CHANGELOG.md

@@ -7,6 +7,48 @@
 ### 🐞 Bug fixes
 - _...Add new stuff here..._
 
+## 0.35.5
+### ✨ Features and improvements
+
+### 🐞 Bug fixes
+- **Requires pmtiles-torrent 0.7.4, which stops archives dropping out of the engine a few more with
+  every restart.** Seen here as `[restore] <archive>: mismatching info-hash`, beginning with one
+  archive and reaching eighteen of twenty. An archive that failed this way was never handed to the
+  engine at all, so the console showed it at 0% with no state, a recheck answered `no such
+  torrent`, and its data sat complete on the disk the whole time — the preview rendered from it
+  perfectly well.
+
+  The sidecar was writing resume data under the wrong torrent's name: saving it was the last thing
+  still popping libtorrent's alert queue on its own thread while the alert pump popped on another,
+  and the pump's next pop freed the batch that loop was reading. `add` then refuses such a file
+  with "mismatching info-hash". 0.7.2 did not introduce it but made the pump pop far more often,
+  which is why it appeared immediately after that upgrade.
+
+  Restarting on this version is the whole recovery: an add refused over resume data is retried
+  without it, and the recheck finds every byte already on disk. Nothing is downloaded again,
+  though rechecking a large archive is not quick.
+
+## 0.35.4
+### ✨ Features and improvements
+
+### 🐞 Bug fixes
+- **Requires pmtiles-torrent 0.7.2, which is what actually stops `libtorrent list timed out after
+  60000ms`.** The console header sat at "connecting…" and clicking an archive never loaded its
+  details, on a node that was otherwise seeding, downloading and serving tiles perfectly well.
+  0.35.1 and 0.35.3 both chased this — through the sidecar's request loop, then through a slow
+  disk — and neither reached it.
+
+  The cost was in the listing itself. Reading one torrent's state is a blocking round-trip to
+  libtorrent's session thread, and the sidecar did three per torrent, so twenty archives cost
+  sixty, each queued behind whatever that one thread was doing. Measured on a session holding
+  twenty torrents: 0.66ms idle against 1001ms with the session busy hashing. The slow disk is real
+  and is what makes the session thread slow — but a slow session thread only becomes a minute of
+  waiting when the call costs sixty round-trips. The sidecar now keeps a status cache fed by
+  asynchronous updates, and listing reads a dictionary.
+
+  `^0.7.1` already admits 0.7.2, so a fresh install picks the fix up on its own. The floor is
+  raised anyway, because a node installed from a lock file does not.
+
 ## 0.35.3
 ### ✨ Features and improvements
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pmtiles-swarm",
-  "version": "0.35.3",
+  "version": "0.35.5",
   "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.7.1",
+    "pmtiles-torrent": "^0.7.4",
     "webtorrent": "^3.0.21"
   },
   "engines": {