partforge 0.130.0 → 0.130.1

package/docs/KERNEL-CONTRACT.md

@@ -857,6 +857,16 @@ 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.
+
 **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.1",
   "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

@@ -12,10 +12,11 @@ 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.
+    // String-namespaced ("cap-N") 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-${nextId++}`;
     return new Promise((resolve) => {
       pending.set(jobId, resolve);

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

@@ -528,14 +528,14 @@ export function mount(part, { createWorker, elements = {}, onBuild, onPick, pick
     // reset the latch instead of stranding it at "requested" forever.
     // String-namespaced ("tess-N"), mirroring capture-build.js's "cap-N" —
     // 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;