@torrent-tv/proxy 2.55.6 → 2.55.8

package/CHANGELOG.md

@@ -1,3 +1,11 @@
+## 2.55.8
+
+- **Fix**: The proxy died twice in one evening (2026-08-22, 15:50:12 and 16:12:21 UTC) with no stop order given, and both deaths are the same fault. The torrent worker thread ends itself when its event loop drains — every recurring interval there is unref'd, upload is disabled by default, and idle peer connections close about half a minute after the traffic stops — so when a viewer paused or left, the thread finished ~35 s later on its own and Node began tearing it down. That teardown touched memory already freed or overwritten (SIGSEGV inside `uv_timer_stop`, reached through `PerIsolatePlatformData::Shutdown`; two core dumps captured identical stacks), and a fault in any thread kills the whole process instantly — HTTP server, tunnel and data channels together, with no log line and no way to restart anything from inside. The HA supervisor restarted the container each time (~15 s), but the browser's reconnect ladder had already given up by then. The worker now keeps ONE interval accounted for (no `.unref()`): an empty tick every 5 s costs nothing, the event loop can never drain while the process lives, and the teardown path — with whatever structure is corrupted inside it — stays unreachable, regardless of which native module is guilty; the three earlier crashes of this family (2026-08-18..21) stay documented under roadmap item 1.
+
+## 2.55.7
+
+- **Fix**: The subtitle push subscription is now recorded under the torrent pool's own key, not the browser's registry key — the two are different strings whenever a source was added by a `.torrent` file (a `.torrent` and a magnet for the same film are different request bytes, hashed into different registry keys, but the SAME infohash) and were silently different in every other case too: a registry key is `sha1(sourceType:source)`, one per API session; the pool's key is `torrent:<infohash>`, deliberately shared across a magnet and a `.torrent` for the same content (item 10). The diagnostic logging added in 2.55.6 caught it directly, field case 2026-08-22: cues were found and logged repeatedly, and every push answered `found no subscribed channel` — the subscription and the publish had never been able to agree on a key, for any torrent, since the push feature shipped in 2.55.5. `data-channel-handler.js` now resolves the browser's registry key through `sourceRegistry` to `(sourceType, source)` and runs it through the same `deriveSourceKey` the pool itself uses, at the one point both keys are in hand — the subscribe intercept, before the request is even forwarded.
+
 ## 2.55.6
 
 - **Chore**: Every step of the subtitle push chain now logs on success, not only on failure. Field report 2026-08-22, playing `Minions.and.Monsters.1080p.mkv`: a track was switched on over a minute after the seed fetch found nothing (`bytes=7`, an empty `WEBVTT` — expected, the torrent had barely started), and no cues appeared. The proxy log carried no evidence either way — `warmActiveFiles` posted `Event.SUBTITLE_CUES_READY` silently, `publishSubtitleCues` sent (or found no subscriber for) a push silently, and `subscribeSubtitles` registered a channel silently. Confirmed separately by reading WebTorrent's own source that `verified` fires on every live piece completion (`_markVerified` inside `store.put`'s callback in `torrent.js`, not only at startup), so the event source itself is real; what could not be told apart without these lines is subscription, discovery, and delivery. Logs now name each: `subtitle push: channel subscribed to …`, `… cue(s) found, posting to main thread`, `… sent N cue(s) … to M/T channel(s)` (or `found no subscribed channel`).

package/bin/cli.js

@@ -300,6 +300,7 @@ try {
   });
   app = started.app;
   actualPort = started.port;
+  const sourceRegistry = started.sourceRegistry;
   const directBaseUrl = explicitBaseUrl || `http://${bindHost}:${actualPort}`;
 
   // A native fault writes the whole address space out — 4.18 GB each on the
@@ -421,6 +422,10 @@ try {
   dataChannelHandler = createDataChannelHandler({
     proxyPort: actualPort,
     onLog: (message) => logger.info(message),
+    // Resolves a browser's registry sourceKey to the torrent pool's own key
+    // (the content's infohash) so the subtitle push subscription and the
+    // pool's own publish agree on what a source is called. See server.js.
+    sourceRegistry,
     // Lets a stuck send queue ask the transport what it is doing. Late-bound:
     // the manager is created below, with this handler already in hand.
     getTransportSnapshot: (sessionId) => webRtcManager?.getTransportSnapshot(sessionId) ?? null

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@torrent-tv/proxy",
-  "version": "2.55.6",
+  "version": "2.55.8",
   "description": "Torrent proxy client that exposes webseed-like HTTP stream endpoint.",
   "license": "GPL-3.0-or-later",
   "publishConfig": {

package/server.js

@@ -290,6 +290,14 @@ export async function startProxyServer({
   await app.listen({ host, port: selectedPort });
   return {
     app,
-    port: selectedPort
+    port: selectedPort,
+    // The browser only ever knows a source by its REGISTRY key (a hash of the
+    // raw request bytes, scoped to one API session) — never the torrent
+    // pool's own key (the content's infohash, shared across a magnet and a
+    // `.torrent` naming the same film). The subtitle push subscription is
+    // recorded from a browser request and published from the pool's side, so
+    // resolving one into the other is what lets the two ends agree on what
+    // they are both calling "sourceKey".
+    sourceRegistry
   };
 }

package/services/data-channel-handler.js

@@ -43,6 +43,8 @@
 
 /** @import { DataChannel } from 'node-datachannel' */
 
+import { deriveSourceKey } from "./torrent-source-key.js";
+
 /**
  * Configuration for the data channel handler.
  *
@@ -299,7 +301,7 @@ export function encodeFrame(idBytes, bytes, done) {
   return frame;
 }
 
-export function createDataChannelHandler({ proxyPort, onLog, getTransportSnapshot }) {
+export function createDataChannelHandler({ proxyPort, onLog, getTransportSnapshot, sourceRegistry }) {
   /**
    * Channels currently interested in one file's subtitle cues, keyed by
    * `sourceKey:fileIndex`. Populated the moment a browser asks for an
@@ -579,13 +581,34 @@ export function createDataChannelHandler({ proxyPort, onLog, getTransportSnapsho
     // this walks incrementally). `fileIndex` alone would also scope this to
     // the wrong grain for the real case — a torrent can carry several playable
     // files — so the pair is what a push is ever addressed to.
+    //
+    // The browser's `sourceKey` is a REGISTRY key — a hash of the raw request
+    // bytes, one per (magnet-or-.torrent, this API session). The torrent pool
+    // publishes under its OWN key — the content's infohash, deliberately the
+    // SAME for a magnet and a `.torrent` naming the same film, so the two
+    // share one swarm (item 10). The two are different strings for the same
+    // torrent whenever a source was added by its `.torrent` file (a `.torrent`
+    // and a magnet are different request bytes, same infohash) — subscribing
+    // under the registry key found no publisher for that reason, not because
+    // nothing was ever read: field case 2026-08-22, cues were found and
+    // logged, every push answered "found no subscribed channel". Resolved to
+    // the pool's key here, the one place both are in hand.
     if (path === "/api/subtitles" && typeof query === "string") {
       const params = new URLSearchParams(query);
-      const sourceKey = params.get("sourceKey");
+      const registrySourceKey = params.get("sourceKey");
       const fileIndex = Number(params.get("fileIndex"));
       const hasTrackIndex = params.get("trackIndex") !== null && params.get("trackIndex") !== "";
-      if (sourceKey && Number.isInteger(fileIndex) && hasTrackIndex) {
-        subscribeSubtitles(sourceKey, fileIndex, channel);
+      if (registrySourceKey && Number.isInteger(fileIndex) && hasTrackIndex) {
+        const record = sourceRegistry?.get(registrySourceKey);
+        if (record) {
+          try {
+            const poolSourceKey = await deriveSourceKey(record.sourceType, record.source);
+            subscribeSubtitles(poolSourceKey, fileIndex, channel);
+          } catch (error) {
+            log(`[dc] subtitle push: could not resolve ${registrySourceKey.slice(0, 8)} to a pool key: ` +
+              `${error instanceof Error ? error.message : error}`);
+          }
+        }
       }
     }
 

package/services/torrent-worker/worker.js

@@ -590,4 +590,31 @@ setInterval(() => {
   }
 }, SUBTITLE_WARMUP_INTERVAL_MS).unref();
 
+/**
+ * Keeps this thread alive ON PURPOSE — the one interval left accounted for
+ * (no `.unref()`).
+ *
+ * Every other recurring handle here is unref'd, upload is disabled by
+ * default, and idle peer connections close about half a minute after the
+ * traffic stops — so once nothing is being read, every handle can be gone
+ * at once, the event loop drains, and this thread ends BY ITSELF. Node then
+ * tears the isolate down, that teardown touches memory some native module
+ * has already freed, and the fault (SIGSEGV inside `uv_timer_stop`, reached
+ * through `PerIsolatePlatformData::Shutdown`) kills the whole process at
+ * once — HTTP server, tunnel, data channels — before any JS handler runs.
+ * Field evidence: two deaths on 2026-08-22 (15:50:12 and 16:12:21 UTC),
+ * each ~35 s after the last byte of traffic, identical core dumps;
+ * same crash family as the utp-native faults of 2026-08-18..21
+ * (`research/worker-thread-drain-crash-2026-08-22.md`).
+ *
+ * An empty repeating interval costs nothing, keeps the loop from draining
+ * while the process lives, and thereby keeps that teardown path — and the
+ * corrupted structure inside it — unreachable, whichever module is guilty.
+ */
+const WORKER_KEEPALIVE_INTERVAL_MS = 5_000;
+
+setInterval(() => {
+  void process.uptime();
+}, WORKER_KEEPALIVE_INTERVAL_MS);
+
 log("torrent worker started");