@norskvideo/ctl-sdk 0.1.47 → 0.1.49

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@norskvideo/ctl-sdk",
-  "version": "0.1.47",
+  "version": "0.1.49",
   "type": "module",
   "exports": {
     ".": {
@@ -44,7 +44,7 @@
   "main": "./index.js",
   "types": "./index.d.ts",
   "dependencies": {
-    "@norskvideo/ctl-foundation": "^0.1.0",
+    "@norskvideo/ctl-foundation": "^0.1.20",
     "@norskvideo/ctl-product-template-schema": "^0.1.20",
     "express": "5",
     "lucide-react": "^0.483.0",

package/product-reach.d.ts

@@ -5,5 +5,7 @@ export type ProductReach = "host" | "container-address";
 export declare function parseContainerIdFromCgroup(text: string): string | null;
 export declare function detectProductReach(opts: {
     cgroup?: () => string;
+    /** Whether /.dockerenv exists; injectable so a test does not read the host it runs on. */
+    dockerenv?: () => boolean;
     env?: Record<string, string | undefined>;
 }): ProductReach;

package/product-reach.js

@@ -5,11 +5,21 @@
 // host, not to the daemon, and every registration times out at readiness. The
 // container's own bridge address on the internal port is what such a daemon
 // can dial, so a containerised daemon uses that and remembers it on the
-// registration (`reachHost`). Detection reads the daemon's own cgroup, the
-// same tell the test harness uses; NORSK_CTL_PRODUCT_REACH overrides it.
-import { readFileSync } from "node:fs";
+// registration (`reachHost`). Detection reads the daemon's own cgroup, then
+// /.dockerenv; NORSK_CTL_PRODUCT_REACH overrides both.
+//
+// The cgroup alone is not enough. Under a cgroup NAMESPACE (docker's default on
+// cgroup v2) a container sees `0::/` and no id, so it reads as a bare host from
+// inside a container. That sent funke's image-mode demo check on an arm DooD
+// runner to 127.0.0.1:<host port> on 2026-10-04, which never answers. The test
+// harness fixed the same false negative in its own resolveContainerId; this is
+// the daemon's copy of that fix. /.dockerenv is written by the docker daemon
+// into every container it creates, and answers the question asked here: is
+// THIS process containerised.
+import { existsSync, readFileSync } from "node:fs";
 const CGROUP_PATH = "/proc/self/cgroup";
 const REACH_ENV = "NORSK_CTL_PRODUCT_REACH";
+const DOCKERENV_PATH = "/.dockerenv";
 /** The 64-hex docker container id from a /proc/self/cgroup dump, or null on a
  *  bare host. Present in both cgroup v1 (`/docker/<id>`) and v2
  *  (`docker-<id>.scope`) layouts. */
@@ -23,10 +33,13 @@ export function detectProductReach(opts) {
     if (forced === "host" || forced === "container-address")
         return forced;
     const read = opts.cgroup ?? (() => readFileSync(CGROUP_PATH, "utf-8"));
+    const dockerenv = opts.dockerenv ?? (() => existsSync(DOCKERENV_PATH));
     try {
-        return parseContainerIdFromCgroup(read()) ? "container-address" : "host";
+        if (parseContainerIdFromCgroup(read()))
+            return "container-address";
     }
     catch {
-        return "host";
+        // No /proc: fall through to the marker file.
     }
+    return dockerenv() ? "container-address" : "host";
 }