partforge 0.130.0 → 0.130.2

package/docs/KERNEL-CONTRACT.md

@@ -857,6 +857,22 @@ Manifold backend, thrown from `imports.js`'s registration policy, not `errors.js
 `KernelCapabilityError`/`NEEDS_OCCT`) — is the same message shape and the same
 non-epoch-gated risk as `needs-occt`; a host handling one should handle both the same way.
 
+**Export replies cross a rebind by design.** Exports run to completion, so a host that
+keeps one worker across mounts, and routes that worker's messages to whichever mount is
+listening now, hands the next mount every reply to the previous mount's exports.
+`mount()` handles this itself. Its export jobIds (`export-<c>-<n>`, and `warm-<c>-<n>`
+for `warmExportKernel`) are unique to each mount, not numbered from 1 per mount. So a
+previous mount's reply can never settle the new mount's export with the old geometry.
+The new mount claims that reply and drops it, rather than letting its own handler read
+the reply's `error` as a failed build or its `download` as a viewbar save. The previous
+mount already rejected that export when it was disposed.
+
+`captureView` replies cross a rebind the same way, and `mount()` handles them the same
+way. Its `capture-generate` jobIds (`cap-<b>-<n>`) are unique to each mount, so a previous
+mount's `capture-meshes` can never settle the new mount's capture with the old geometry,
+and the new mount claims and drops that reply, including an `error`. The previous mount
+already resolved that capture to `null` when it was disposed.
+
 **Cancellation granularity is the sub-part.** The guard is checked only between
 sub-parts (one macrotask yield each), so a single long WASM op — a big boolean, an OCCT
 fillet — runs to completion no matter how stale it is. That is by design: WASM kernel

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "partforge",
-  "version": "0.130.0",
+  "version": "0.130.2",
   "description": "Turn a declarative part definition into a parametric-CAD web app (three.js + Manifold/Replicad). Requires a Vite-based consumer.",
   "type": "module",
   "license": "MIT",

package/src/framework/capture-build.js

@@ -2,7 +2,23 @@
 // does NOT go through the regen loop. Same shape as export-controller's pending
 // Map (export-controller.js): allocate a jobId, resolve when the matching
 // reply arrives. Pure — no DOM, no worker; `send` is injected.
+
+// Job ids are unique per capture build, not just per mount: `cap-<b>-<n>`,
+// where <b> numbers the capture builds this module has made. Each mount makes
+// one, but a host may keep a worker across mounts (partforge-cloud's pool
+// rebinds it with setPart), and that worker's replies then reach whichever
+// mount is listening now. A capture-generate runs to completion, so a disposed
+// mount's capture still answers after the remount. When every mount numbered
+// its captures from 1, that late reply settled the next mount's same-numbered
+// capture with pre-edit geometry. The same scheme as export-controller.js's
+// `export-<c>-<n>`.
+let builds = 0;
+// Every id any capture build mints, so a reply to another build's job is
+// recognised even though this build never sent it.
+const CAPTURE_JOB_ID = /^cap-\d+-\d+$/;
+
 export function createCaptureBuild({ send }) {
+  const build = ++builds;
   let nextId = 1;
   let disposed = false;
   const pending = new Map(); // jobId -> resolve
@@ -12,11 +28,12 @@ export function createCaptureBuild({ send }) {
     // worker (a silent no-op) and its promise would hang forever. Resolve null instead
     // — captureView's documented "disposed runtime resolves null" contract.
     if (disposed) return Promise.resolve(null);
-    // String-namespaced ("cap-N") so a capture jobId can never collide with
-    // export-controller's numeric jobIds — both share the same worker message
-    // space, and exportCtl.handleMessage does a raw pending.get(m.jobId) before
-    // checking type, so a colliding id could otherwise settle the wrong promise.
-    const jobId = `cap-${nextId++}`;
+    // String-namespaced ("cap-") so a capture jobId stays outside
+    // export-controller's "export-"/"warm-" ids — both share the same worker
+    // message space, and exportCtl.handleMessage claims every id in its own
+    // namespace before checking type, so a colliding id could otherwise settle
+    // the wrong promise.
+    const jobId = `cap-${build}-${nextId++}`;
     return new Promise((resolve) => {
       pending.set(jobId, resolve);
       // cache:true so the worker reuses its per-sub-part geometry memo (the
@@ -25,13 +42,14 @@ export function createCaptureBuild({ send }) {
     });
   }
 
-  // Returns true iff this message was a reply this controller owns (so the
-  // caller — mount.js's onWorkerMessage — can skip it entirely). Keyed on
-  // membership in `pending` first: the namespaced jobId guarantees another
-  // channel's message never matches, so a hit here is always ours. A failed
-  // build (the worker's shared catch posts a generic error/needs-occt/
-  // needs-import-mesh, jobId intact) resolves to null rather than leaving the
-  // caller hanging forever — captureView treats null as "capture failed, skip".
+  // Returns true iff this message is a reply to a capture job (so the caller —
+  // mount.js's onWorkerMessage — can skip it entirely): a pending job is
+  // settled, any other capture id is dropped. Keyed on membership in `pending`
+  // first: the namespaced jobId guarantees another channel's message never
+  // matches, so a hit here is always ours. A failed build (the worker's shared
+  // catch posts a generic error/needs-occt/needs-import-mesh, jobId intact)
+  // resolves to null rather than leaving the caller hanging forever —
+  // captureView treats null as "capture failed, skip".
   // needs-import-mesh MUST be claimed here rather than falling through to
   // mount's live-loop crossover case: this capture job never went through the
   // regen loop, so treating its reply as a live crossover would call
@@ -42,7 +60,12 @@ export function createCaptureBuild({ send }) {
   // gets primed by the next live build instead.
   function handleMessage(data) {
     const jobId = data?.jobId;
-    if (jobId == null || !pending.has(jobId)) return false;
+    // A capture id with nothing pending here: a job this build already
+    // settled, or one a disposed build sent to a worker the host kept. Either
+    // way its promise is already settled, so claim the reply and drop it.
+    // Passing it on would let mount's switch read an "error" as a failed build
+    // and a needs-import-mesh as a live crossover.
+    if (jobId == null || !pending.has(jobId)) return typeof jobId === "string" && CAPTURE_JOB_ID.test(jobId);
     if (data.type === "capture-meshes") {
       pending.get(jobId)(data.meshes);
     } else if (data.type === "error" || data.type === "needs-occt" || data.type === "needs-import-mesh") {

package/src/framework/export-controller.js

@@ -15,17 +15,32 @@ export function backendForFormat(format, defaultBackend) {
   return format === "step" ? "occt" : defaultBackend();
 }
 
+// Job ids are unique per controller, not just per mount: `export-<c>-<n>` and
+// `warm-<c>-<n>`, where <c> numbers the controllers this module has made. Each
+// mount makes one controller, but a host may keep a worker across mounts
+// (partforge-cloud's pool rebinds it with setPart), and that worker's replies
+// then reach whichever mount is listening now. Exports are never epoch-guarded
+// (KERNEL-CONTRACT), so a disposed mount's slow export still answers after the
+// remount. When every mount numbered its jobs from 1, that late reply settled
+// the next mount's same-numbered export with pre-edit geometry. A worker can
+// only be shared within one realm, and this counter covers the whole realm.
+let controllers = 0;
+// Every id any controller mints, so a reply to another controller's job is
+// recognised even though this controller never sent it.
+const CONTROLLER_JOB_ID = /^(?:export|warm)-\d+-\d+$/;
+
 export function createExportController({ send, currentView, title, defaultBackend = () => "manifold", currentParams = () => ({}) }) {
   const pending = new Map(); // jobId -> { resolve, reject, onProgress }
+  const controller = ++controllers;
   let nextId = 1;
-  // Warm jobs are STRING-namespaced ("warm-N") for the reason mount.js spells
-  // out for tessellate-imports: this map is keyed by jobId alone and read before
-  // any type check, so a bare numeric id here could be claimed by a pending
-  // export (both counters start at 1) and settle the wrong Promise.
+  // Warm jobs get their own prefix for the reason mount.js spells out for
+  // tessellate-imports: this map is keyed by jobId alone and read before any
+  // type check, so a warm and an export sharing an id would settle each
+  // other's Promise.
   let nextWarmId = 1;
 
   function exportParts({ parts, format, quality = "print", onProgress } = {}) {
-    const jobId = nextId++;
+    const jobId = `export-${controller}-${nextId++}`;
     const type = `export-${format}`;
     const backend = backendForFormat(format, defaultBackend);
     return new Promise((resolve, reject) => {
@@ -45,18 +60,25 @@ export function createExportController({ send, currentView, title, defaultBacken
   // failure or teardown, and NEVER rejects — a speculative warm must not become
   // an unhandled rejection in a host that fired it and moved on.
   function warmKernel() {
-    const jobId = `warm-${nextWarmId++}`;
+    const jobId = `warm-${controller}-${nextWarmId++}`;
     return new Promise((resolve) => {
       pending.set(jobId, { resolve: () => resolve(true), reject: () => resolve(false) });
       send({ type: "warm-kernel", jobId }, backendForFormat("step", defaultBackend));
     });
   }
 
-  // Returns true iff this message belonged to a pending export (so the caller
-  // can skip legacy handling). `sink` is partforge's onDownload.
+  // Returns true iff this message is a reply to an export-controller job (so
+  // the caller can skip legacy handling): a pending job is settled, any other
+  // is dropped. `sink` is partforge's onDownload.
   function handleMessage(m, sink) {
-    const entry = m && m.jobId != null ? pending.get(m.jobId) : undefined;
-    if (!entry) return false;
+    const jobId = m?.jobId;
+    const entry = jobId != null ? pending.get(jobId) : undefined;
+    // A controller's id with nothing pending here: a job this controller
+    // already settled, or one a disposed controller sent to a worker the host
+    // kept. Either way its Promise is already settled, so claim the reply and
+    // drop it. Passing it on would let mount's switch read an "error" as a
+    // failed build and a "download" as a viewbar save.
+    if (!entry) return typeof jobId === "string" && CONTROLLER_JOB_ID.test(jobId);
     if (m.type === "progress") { entry.onProgress?.(m.phase); return true; }
     if (m.type === "kernel-warm") { pending.delete(m.jobId); entry.resolve(); return true; }
     if (m.type === "download") {

package/src/framework/mount.js

@@ -526,16 +526,16 @@ export function mount(part, { createWorker, elements = {}, onBuild, onPick, pick
     // Lets the "error" case below tell a correlated tessellation failure apart
     // from an unrelated build error sharing the same message type, so it can
     // reset the latch instead of stranding it at "requested" forever.
-    // String-namespaced ("tess-N"), mirroring capture-build.js's "cap-N" —
+    // String-namespaced ("tess-N"), mirroring capture-build.js's "cap-" ids —
     // this request shares the OCCT worker's message space with
-    // export-controller's PLAIN NUMERIC jobIds (both start counting at 1), and
-    // exportCtl.handleMessage (called before mount's own switch, below) does a
-    // raw pending.get(m.jobId) before checking type. A bare numeric id here
-    // could collide with a pending STEP export's jobId, so the export
-    // controller would wrongly claim this reply — rejecting an unrelated
-    // export with the tessellation failure text AND leaving importMeshState
-    // stranded at "requested" (mount's own switch, which would have reset it,
-    // never runs). The string namespace makes that collision impossible.
+    // export-controller's "export-"/"warm-" jobIds, and exportCtl.handleMessage
+    // (called before mount's own switch, below) claims every id in its own
+    // namespace before checking type. An id inside that namespace would let the
+    // export controller wrongly claim this reply — rejecting an unrelated
+    // export with the tessellation failure text, or dropping the reply, AND
+    // leaving importMeshState stranded at "requested" (mount's own switch,
+    // which would have reset it, never runs). The "tess-" prefix makes that
+    // collision impossible.
     let importTessellateJobId = null;
     let importTessellateJobSeq = 0;
 
@@ -1015,6 +1015,8 @@ export function mount(part, { createWorker, elements = {}, onBuild, onPick, pick
       if (exportCtl.handleMessage(data, onDownload)) return;
       // captureView's off-loop build channel: consume its replies before the
       // live `meshes` case — capture-meshes must never touch live cache/display.
+      // Like exportCtl, it also claims a disposed mount's late capture reply on
+      // a worker the host kept, so a stale "error" never reads as a failed build.
       if (captureBuild.handleMessage(data)) return;
       switch (data.type) {
         case "ready":