@valbuild/server 0.103.1 → 0.103.2

package/dist/valbuild-server.cjs.dev.js

@@ -5442,6 +5442,112 @@ class FSOpsHost {
   }
 }
 
+/**
+ * Which unpublished changes a failed save has to throw away to make progress.
+ *
+ * `/save` used to refuse the whole commit when any one patch could not be
+ * applied: nothing was written, for any module, and the change stayed on disk to
+ * fail again on the next attempt. With auto-save that is not a refusal, it is a
+ * dead stop — the editor keeps typing, every save fails on the same patch, and
+ * nothing is ever written again.
+ *
+ * So in `fs` mode the failing change is removed instead, and the person editing
+ * is told. The rule for what goes with it:
+ *
+ * **From the first failure onward, within that module.** A patch is a set of ops
+ * against the source as the patches before it left it. Once one has not been
+ * applied, every later patch in that module was computed against a state that no
+ * longer exists, so keeping them would be keeping changes whose meaning has
+ * already been lost. That is `triedPatches` (the one that failed) plus
+ * `skippedPatches` (the tail that was never attempted).
+ *
+ * **Other modules are untouched.** `prepare` walks each module's chain
+ * independently, so a broken chain in one file says nothing about another.
+ *
+ * **And a module that failed as a WHOLE keeps everything.** When the `.val.ts`
+ * cannot be read at all, `prepare` reports every one of its patches as skipped
+ * and names none of them as unappliable — the file is what failed, not the
+ * changes. Deleting them there would be destroying good edits because a file was
+ * missing for a moment: rename a module, or switch branch, with unsaved changes
+ * to it and the next auto-save would silently take them all. Skipped is only
+ * collateral when there is something in that module for it to be collateral OF.
+ */
+
+/**
+ * The message for a patch that did not itself fail but sits behind one that did.
+ *
+ * Worth distinguishing: "yours was broken" and "something before yours was
+ * broken" are different things to be told, and only the first is a bug in the
+ * change itself.
+ */
+function collateralMessage(moduleFilePath) {
+  return `An earlier change to ${moduleFilePath} could not be applied, so this one no longer fits the content it was written against.`;
+}
+function computePatchesToDrop(prepared) {
+  const dropped = [];
+  const seen = new Set();
+  const add = (moduleFilePath, patchId) => {
+    var _prepared$unappliable;
+    if (seen.has(patchId)) {
+      return;
+    }
+    seen.add(patchId);
+    dropped.push({
+      patchId,
+      moduleFilePath,
+      message: ((_prepared$unappliable = prepared.unappliablePatches[patchId]) === null || _prepared$unappliable === void 0 ? void 0 : _prepared$unappliable.message) ?? collateralMessage(moduleFilePath)
+    });
+  };
+
+  // Tried before skipped, so the change that actually failed is named first —
+  // it is the one worth reading.
+  for (const [moduleFilePath, patchIds] of Object.entries(prepared.triedPatches)) {
+    for (const patchId of patchIds) {
+      add(moduleFilePath, patchId);
+    }
+  }
+  /*
+   * Which modules actually had a change fail, as opposed to being unreadable.
+   *
+   * `triedPatches` holds only failures, and `unappliablePatches` names the
+   * failure itself, so between them they are the whole answer. A module in
+   * neither has nothing to blame its skipped tail on.
+   */
+  const failedModules = new Set();
+  for (const [moduleFilePath, patchIds] of Object.entries(prepared.triedPatches)) {
+    if (patchIds.length > 0) {
+      failedModules.add(moduleFilePath);
+    }
+  }
+  for (const failure of Object.values(prepared.unappliablePatches)) {
+    failedModules.add(failure.moduleFilePath);
+  }
+  for (const [moduleFilePath, patchIds] of Object.entries(prepared.skippedPatches)) {
+    if (!failedModules.has(moduleFilePath)) {
+      // The module failed as a whole. Its changes are fine and are kept, so the
+      // save refuses instead — which is what it did before auto-save, and is
+      // right here: this one resolves itself when the file comes back.
+      continue;
+    }
+    for (const patchId of patchIds) {
+      add(moduleFilePath, patchId);
+    }
+  }
+
+  /*
+   * A patch reported unappliable that neither list holds.
+   *
+   * Belt and braces: the two lists are how `prepare` reports the shape of the
+   * failure, and this is how it reports the failure itself. If they ever
+   * disagree, leaving a patch behind means the next save fails on it again —
+   * the exact dead stop this function exists to prevent.
+   */
+  for (const [patchId, failure] of Object.entries(prepared.unappliablePatches)) {
+    add(failure.moduleFilePath, patchId);
+  }
+  return dropped;
+}
+
 const textEncoder$2 = new TextEncoder();
 const PatchId = z.z.string().refine(s => !!s); // TODO: validate
 const CommitSha = z.z.string().refine(s => !!s); // TODO: validate
@@ -8139,11 +8245,65 @@ const ValServer = (valModules, options, callbacks) => {
           patchIds,
           excludePatchOps: false
         });
+        /*
+         * Exactly the patches this request consumes, and the ONLY ones it may
+         * delete afterwards.
+         *
+         * Taken from what was fetched rather than from what was asked for, and
+         * held across everything below, because the store keeps accepting writes
+         * while this runs. A change typed during a save is not in this list, is
+         * not applied, and must still be here when the save finishes — that is
+         * the whole contract, and `deleteAllPatches` broke it by removing the
+         * store wholesale.
+         */
+        const consumed = patches.patches.map(patch => patch.patchId);
         const analysis = serverOps.analyzePatches(patches.patches, patches.commits, commit);
-        const preparedCommit = await serverOps.prepare({
+        let preparedCommit = await serverOps.prepare({
           ...analysis,
           ...patches
         });
+        /*
+         * In `fs` mode a change that cannot be applied is removed rather than
+         * blocking the save.
+         *
+         * Refusing the whole commit is right for a git commit — it is one
+         * atomic thing, and the content api owns its own patches. It is wrong
+         * for auto-save: the editor keeps typing, every save fails on the same
+         * patch, and nothing is ever written again. So the failing change and
+         * the rest of its module's chain go, the rest is written, and the person
+         * editing is told what was thrown away.
+         */
+        let removed = [];
+        if (preparedCommit.hasErrors && serverOps instanceof ValOpsFS) {
+          removed = computePatchesToDrop(preparedCommit);
+          /*
+           * Nothing to drop means nothing a second `prepare` could do better.
+           *
+           * `hasErrors` covers failures no patch is to blame for — a binary file
+           * that could not be written, a module that could not be formatted, a
+           * `.val.ts` that could not be read at all. Re-preparing every module
+           * with an unchanged patch set would fail identically, and logging
+           * "removed unpublished changes []" on the way would say something
+           * untrue. It falls through to the 400 instead, which is the honest
+           * answer: this save did not happen and the changes are still here.
+           */
+          if (removed.length > 0) {
+            const doomed = new Set(removed.map(entry => entry.patchId));
+            const survivors = patches.patches.filter(patch => !doomed.has(patch.patchId));
+            const survivingPatches = {
+              ...patches,
+              patches: survivors
+            };
+            // One retry is enough: what is left of each module is the prefix
+            // that already applied, and `prepare` walks modules independently,
+            // so nothing new can fail.
+            preparedCommit = await serverOps.prepare({
+              ...serverOps.analyzePatches(survivors, patches.commits, commit),
+              ...survivingPatches
+            });
+            console.error("Val: removed unpublished changes that could not be applied", removed);
+          }
+        }
         if (preparedCommit.hasErrors) {
           console.error("Failed to create commit", JSON.stringify({
             sourceFilePatchErrors: preparedCommit.sourceFilePatchErrors,
@@ -8196,13 +8356,31 @@ const ValServer = (valModules, options, callbacks) => {
               }
             };
           }
-          const deleteRes = await serverOps.deleteAllPatches();
-          if (deleteRes.error) {
+          /*
+           * Only what this request consumed.
+           *
+           * This used to be `deleteAllPatches()`, which renamed the whole store
+           * aside and deleted it. Anything typed while the save was in flight
+           * went with it — never applied, and indistinguishable on the client
+           * from having been published, because both look like "the patch is
+           * gone and the base moved". A visible edit that exists nowhere on
+           * disk, with nothing reporting a problem.
+           */
+          const deleteRes = await serverOps.deletePatches(consumed);
+          if ("error" in deleteRes && deleteRes.error !== undefined) {
             console.error(`Val got an error while cleaning up patches after publish: ${deleteRes.error.message}`);
+          } else if ("errors" in deleteRes && deleteRes.errors !== undefined) {
+            // Per patch, and not fatal: the files are written, so the save
+            // succeeded. A patch left behind is announced again on the next
+            // stat, applies to a base that already contains it, and is removed
+            // then.
+            console.error("Val: could not clean up some patches after publish", deleteRes.errors);
           }
           return {
             status: 200,
-            json: {} // TODO:
+            json: removed.length > 0 ? {
+              removed
+            } : {}
           };
         } else if (serverOps instanceof ValOpsHttp) {
           if (auth.error === undefined && auth.id) {

package/dist/valbuild-server.cjs.prod.js

@@ -5442,6 +5442,112 @@ class FSOpsHost {
   }
 }
 
+/**
+ * Which unpublished changes a failed save has to throw away to make progress.
+ *
+ * `/save` used to refuse the whole commit when any one patch could not be
+ * applied: nothing was written, for any module, and the change stayed on disk to
+ * fail again on the next attempt. With auto-save that is not a refusal, it is a
+ * dead stop — the editor keeps typing, every save fails on the same patch, and
+ * nothing is ever written again.
+ *
+ * So in `fs` mode the failing change is removed instead, and the person editing
+ * is told. The rule for what goes with it:
+ *
+ * **From the first failure onward, within that module.** A patch is a set of ops
+ * against the source as the patches before it left it. Once one has not been
+ * applied, every later patch in that module was computed against a state that no
+ * longer exists, so keeping them would be keeping changes whose meaning has
+ * already been lost. That is `triedPatches` (the one that failed) plus
+ * `skippedPatches` (the tail that was never attempted).
+ *
+ * **Other modules are untouched.** `prepare` walks each module's chain
+ * independently, so a broken chain in one file says nothing about another.
+ *
+ * **And a module that failed as a WHOLE keeps everything.** When the `.val.ts`
+ * cannot be read at all, `prepare` reports every one of its patches as skipped
+ * and names none of them as unappliable — the file is what failed, not the
+ * changes. Deleting them there would be destroying good edits because a file was
+ * missing for a moment: rename a module, or switch branch, with unsaved changes
+ * to it and the next auto-save would silently take them all. Skipped is only
+ * collateral when there is something in that module for it to be collateral OF.
+ */
+
+/**
+ * The message for a patch that did not itself fail but sits behind one that did.
+ *
+ * Worth distinguishing: "yours was broken" and "something before yours was
+ * broken" are different things to be told, and only the first is a bug in the
+ * change itself.
+ */
+function collateralMessage(moduleFilePath) {
+  return `An earlier change to ${moduleFilePath} could not be applied, so this one no longer fits the content it was written against.`;
+}
+function computePatchesToDrop(prepared) {
+  const dropped = [];
+  const seen = new Set();
+  const add = (moduleFilePath, patchId) => {
+    var _prepared$unappliable;
+    if (seen.has(patchId)) {
+      return;
+    }
+    seen.add(patchId);
+    dropped.push({
+      patchId,
+      moduleFilePath,
+      message: ((_prepared$unappliable = prepared.unappliablePatches[patchId]) === null || _prepared$unappliable === void 0 ? void 0 : _prepared$unappliable.message) ?? collateralMessage(moduleFilePath)
+    });
+  };
+
+  // Tried before skipped, so the change that actually failed is named first —
+  // it is the one worth reading.
+  for (const [moduleFilePath, patchIds] of Object.entries(prepared.triedPatches)) {
+    for (const patchId of patchIds) {
+      add(moduleFilePath, patchId);
+    }
+  }
+  /*
+   * Which modules actually had a change fail, as opposed to being unreadable.
+   *
+   * `triedPatches` holds only failures, and `unappliablePatches` names the
+   * failure itself, so between them they are the whole answer. A module in
+   * neither has nothing to blame its skipped tail on.
+   */
+  const failedModules = new Set();
+  for (const [moduleFilePath, patchIds] of Object.entries(prepared.triedPatches)) {
+    if (patchIds.length > 0) {
+      failedModules.add(moduleFilePath);
+    }
+  }
+  for (const failure of Object.values(prepared.unappliablePatches)) {
+    failedModules.add(failure.moduleFilePath);
+  }
+  for (const [moduleFilePath, patchIds] of Object.entries(prepared.skippedPatches)) {
+    if (!failedModules.has(moduleFilePath)) {
+      // The module failed as a whole. Its changes are fine and are kept, so the
+      // save refuses instead — which is what it did before auto-save, and is
+      // right here: this one resolves itself when the file comes back.
+      continue;
+    }
+    for (const patchId of patchIds) {
+      add(moduleFilePath, patchId);
+    }
+  }
+
+  /*
+   * A patch reported unappliable that neither list holds.
+   *
+   * Belt and braces: the two lists are how `prepare` reports the shape of the
+   * failure, and this is how it reports the failure itself. If they ever
+   * disagree, leaving a patch behind means the next save fails on it again —
+   * the exact dead stop this function exists to prevent.
+   */
+  for (const [patchId, failure] of Object.entries(prepared.unappliablePatches)) {
+    add(failure.moduleFilePath, patchId);
+  }
+  return dropped;
+}
+
 const textEncoder$2 = new TextEncoder();
 const PatchId = z.z.string().refine(s => !!s); // TODO: validate
 const CommitSha = z.z.string().refine(s => !!s); // TODO: validate
@@ -8139,11 +8245,65 @@ const ValServer = (valModules, options, callbacks) => {
           patchIds,
           excludePatchOps: false
         });
+        /*
+         * Exactly the patches this request consumes, and the ONLY ones it may
+         * delete afterwards.
+         *
+         * Taken from what was fetched rather than from what was asked for, and
+         * held across everything below, because the store keeps accepting writes
+         * while this runs. A change typed during a save is not in this list, is
+         * not applied, and must still be here when the save finishes — that is
+         * the whole contract, and `deleteAllPatches` broke it by removing the
+         * store wholesale.
+         */
+        const consumed = patches.patches.map(patch => patch.patchId);
         const analysis = serverOps.analyzePatches(patches.patches, patches.commits, commit);
-        const preparedCommit = await serverOps.prepare({
+        let preparedCommit = await serverOps.prepare({
           ...analysis,
           ...patches
         });
+        /*
+         * In `fs` mode a change that cannot be applied is removed rather than
+         * blocking the save.
+         *
+         * Refusing the whole commit is right for a git commit — it is one
+         * atomic thing, and the content api owns its own patches. It is wrong
+         * for auto-save: the editor keeps typing, every save fails on the same
+         * patch, and nothing is ever written again. So the failing change and
+         * the rest of its module's chain go, the rest is written, and the person
+         * editing is told what was thrown away.
+         */
+        let removed = [];
+        if (preparedCommit.hasErrors && serverOps instanceof ValOpsFS) {
+          removed = computePatchesToDrop(preparedCommit);
+          /*
+           * Nothing to drop means nothing a second `prepare` could do better.
+           *
+           * `hasErrors` covers failures no patch is to blame for — a binary file
+           * that could not be written, a module that could not be formatted, a
+           * `.val.ts` that could not be read at all. Re-preparing every module
+           * with an unchanged patch set would fail identically, and logging
+           * "removed unpublished changes []" on the way would say something
+           * untrue. It falls through to the 400 instead, which is the honest
+           * answer: this save did not happen and the changes are still here.
+           */
+          if (removed.length > 0) {
+            const doomed = new Set(removed.map(entry => entry.patchId));
+            const survivors = patches.patches.filter(patch => !doomed.has(patch.patchId));
+            const survivingPatches = {
+              ...patches,
+              patches: survivors
+            };
+            // One retry is enough: what is left of each module is the prefix
+            // that already applied, and `prepare` walks modules independently,
+            // so nothing new can fail.
+            preparedCommit = await serverOps.prepare({
+              ...serverOps.analyzePatches(survivors, patches.commits, commit),
+              ...survivingPatches
+            });
+            console.error("Val: removed unpublished changes that could not be applied", removed);
+          }
+        }
         if (preparedCommit.hasErrors) {
           console.error("Failed to create commit", JSON.stringify({
             sourceFilePatchErrors: preparedCommit.sourceFilePatchErrors,
@@ -8196,13 +8356,31 @@ const ValServer = (valModules, options, callbacks) => {
               }
             };
           }
-          const deleteRes = await serverOps.deleteAllPatches();
-          if (deleteRes.error) {
+          /*
+           * Only what this request consumed.
+           *
+           * This used to be `deleteAllPatches()`, which renamed the whole store
+           * aside and deleted it. Anything typed while the save was in flight
+           * went with it — never applied, and indistinguishable on the client
+           * from having been published, because both look like "the patch is
+           * gone and the base moved". A visible edit that exists nowhere on
+           * disk, with nothing reporting a problem.
+           */
+          const deleteRes = await serverOps.deletePatches(consumed);
+          if ("error" in deleteRes && deleteRes.error !== undefined) {
             console.error(`Val got an error while cleaning up patches after publish: ${deleteRes.error.message}`);
+          } else if ("errors" in deleteRes && deleteRes.errors !== undefined) {
+            // Per patch, and not fatal: the files are written, so the save
+            // succeeded. A patch left behind is announced again on the next
+            // stat, applies to a base that already contains it, and is removed
+            // then.
+            console.error("Val: could not clean up some patches after publish", deleteRes.errors);
           }
           return {
             status: 200,
-            json: {} // TODO:
+            json: removed.length > 0 ? {
+              removed
+            } : {}
           };
         } else if (serverOps instanceof ValOpsHttp) {
           if (auth.error === undefined && auth.id) {

package/dist/valbuild-server.esm.js

@@ -5408,6 +5408,112 @@ class FSOpsHost {
   }
 }
 
+/**
+ * Which unpublished changes a failed save has to throw away to make progress.
+ *
+ * `/save` used to refuse the whole commit when any one patch could not be
+ * applied: nothing was written, for any module, and the change stayed on disk to
+ * fail again on the next attempt. With auto-save that is not a refusal, it is a
+ * dead stop — the editor keeps typing, every save fails on the same patch, and
+ * nothing is ever written again.
+ *
+ * So in `fs` mode the failing change is removed instead, and the person editing
+ * is told. The rule for what goes with it:
+ *
+ * **From the first failure onward, within that module.** A patch is a set of ops
+ * against the source as the patches before it left it. Once one has not been
+ * applied, every later patch in that module was computed against a state that no
+ * longer exists, so keeping them would be keeping changes whose meaning has
+ * already been lost. That is `triedPatches` (the one that failed) plus
+ * `skippedPatches` (the tail that was never attempted).
+ *
+ * **Other modules are untouched.** `prepare` walks each module's chain
+ * independently, so a broken chain in one file says nothing about another.
+ *
+ * **And a module that failed as a WHOLE keeps everything.** When the `.val.ts`
+ * cannot be read at all, `prepare` reports every one of its patches as skipped
+ * and names none of them as unappliable — the file is what failed, not the
+ * changes. Deleting them there would be destroying good edits because a file was
+ * missing for a moment: rename a module, or switch branch, with unsaved changes
+ * to it and the next auto-save would silently take them all. Skipped is only
+ * collateral when there is something in that module for it to be collateral OF.
+ */
+
+/**
+ * The message for a patch that did not itself fail but sits behind one that did.
+ *
+ * Worth distinguishing: "yours was broken" and "something before yours was
+ * broken" are different things to be told, and only the first is a bug in the
+ * change itself.
+ */
+function collateralMessage(moduleFilePath) {
+  return `An earlier change to ${moduleFilePath} could not be applied, so this one no longer fits the content it was written against.`;
+}
+function computePatchesToDrop(prepared) {
+  const dropped = [];
+  const seen = new Set();
+  const add = (moduleFilePath, patchId) => {
+    var _prepared$unappliable;
+    if (seen.has(patchId)) {
+      return;
+    }
+    seen.add(patchId);
+    dropped.push({
+      patchId,
+      moduleFilePath,
+      message: ((_prepared$unappliable = prepared.unappliablePatches[patchId]) === null || _prepared$unappliable === void 0 ? void 0 : _prepared$unappliable.message) ?? collateralMessage(moduleFilePath)
+    });
+  };
+
+  // Tried before skipped, so the change that actually failed is named first —
+  // it is the one worth reading.
+  for (const [moduleFilePath, patchIds] of Object.entries(prepared.triedPatches)) {
+    for (const patchId of patchIds) {
+      add(moduleFilePath, patchId);
+    }
+  }
+  /*
+   * Which modules actually had a change fail, as opposed to being unreadable.
+   *
+   * `triedPatches` holds only failures, and `unappliablePatches` names the
+   * failure itself, so between them they are the whole answer. A module in
+   * neither has nothing to blame its skipped tail on.
+   */
+  const failedModules = new Set();
+  for (const [moduleFilePath, patchIds] of Object.entries(prepared.triedPatches)) {
+    if (patchIds.length > 0) {
+      failedModules.add(moduleFilePath);
+    }
+  }
+  for (const failure of Object.values(prepared.unappliablePatches)) {
+    failedModules.add(failure.moduleFilePath);
+  }
+  for (const [moduleFilePath, patchIds] of Object.entries(prepared.skippedPatches)) {
+    if (!failedModules.has(moduleFilePath)) {
+      // The module failed as a whole. Its changes are fine and are kept, so the
+      // save refuses instead — which is what it did before auto-save, and is
+      // right here: this one resolves itself when the file comes back.
+      continue;
+    }
+    for (const patchId of patchIds) {
+      add(moduleFilePath, patchId);
+    }
+  }
+
+  /*
+   * A patch reported unappliable that neither list holds.
+   *
+   * Belt and braces: the two lists are how `prepare` reports the shape of the
+   * failure, and this is how it reports the failure itself. If they ever
+   * disagree, leaving a patch behind means the next save fails on it again —
+   * the exact dead stop this function exists to prevent.
+   */
+  for (const [patchId, failure] of Object.entries(prepared.unappliablePatches)) {
+    add(failure.moduleFilePath, patchId);
+  }
+  return dropped;
+}
+
 const textEncoder$2 = new TextEncoder();
 const PatchId = z.string().refine(s => !!s); // TODO: validate
 const CommitSha = z.string().refine(s => !!s); // TODO: validate
@@ -8105,11 +8211,65 @@ const ValServer = (valModules, options, callbacks) => {
           patchIds,
           excludePatchOps: false
         });
+        /*
+         * Exactly the patches this request consumes, and the ONLY ones it may
+         * delete afterwards.
+         *
+         * Taken from what was fetched rather than from what was asked for, and
+         * held across everything below, because the store keeps accepting writes
+         * while this runs. A change typed during a save is not in this list, is
+         * not applied, and must still be here when the save finishes — that is
+         * the whole contract, and `deleteAllPatches` broke it by removing the
+         * store wholesale.
+         */
+        const consumed = patches.patches.map(patch => patch.patchId);
         const analysis = serverOps.analyzePatches(patches.patches, patches.commits, commit);
-        const preparedCommit = await serverOps.prepare({
+        let preparedCommit = await serverOps.prepare({
           ...analysis,
           ...patches
         });
+        /*
+         * In `fs` mode a change that cannot be applied is removed rather than
+         * blocking the save.
+         *
+         * Refusing the whole commit is right for a git commit — it is one
+         * atomic thing, and the content api owns its own patches. It is wrong
+         * for auto-save: the editor keeps typing, every save fails on the same
+         * patch, and nothing is ever written again. So the failing change and
+         * the rest of its module's chain go, the rest is written, and the person
+         * editing is told what was thrown away.
+         */
+        let removed = [];
+        if (preparedCommit.hasErrors && serverOps instanceof ValOpsFS) {
+          removed = computePatchesToDrop(preparedCommit);
+          /*
+           * Nothing to drop means nothing a second `prepare` could do better.
+           *
+           * `hasErrors` covers failures no patch is to blame for — a binary file
+           * that could not be written, a module that could not be formatted, a
+           * `.val.ts` that could not be read at all. Re-preparing every module
+           * with an unchanged patch set would fail identically, and logging
+           * "removed unpublished changes []" on the way would say something
+           * untrue. It falls through to the 400 instead, which is the honest
+           * answer: this save did not happen and the changes are still here.
+           */
+          if (removed.length > 0) {
+            const doomed = new Set(removed.map(entry => entry.patchId));
+            const survivors = patches.patches.filter(patch => !doomed.has(patch.patchId));
+            const survivingPatches = {
+              ...patches,
+              patches: survivors
+            };
+            // One retry is enough: what is left of each module is the prefix
+            // that already applied, and `prepare` walks modules independently,
+            // so nothing new can fail.
+            preparedCommit = await serverOps.prepare({
+              ...serverOps.analyzePatches(survivors, patches.commits, commit),
+              ...survivingPatches
+            });
+            console.error("Val: removed unpublished changes that could not be applied", removed);
+          }
+        }
         if (preparedCommit.hasErrors) {
           console.error("Failed to create commit", JSON.stringify({
             sourceFilePatchErrors: preparedCommit.sourceFilePatchErrors,
@@ -8162,13 +8322,31 @@ const ValServer = (valModules, options, callbacks) => {
               }
             };
           }
-          const deleteRes = await serverOps.deleteAllPatches();
-          if (deleteRes.error) {
+          /*
+           * Only what this request consumed.
+           *
+           * This used to be `deleteAllPatches()`, which renamed the whole store
+           * aside and deleted it. Anything typed while the save was in flight
+           * went with it — never applied, and indistinguishable on the client
+           * from having been published, because both look like "the patch is
+           * gone and the base moved". A visible edit that exists nowhere on
+           * disk, with nothing reporting a problem.
+           */
+          const deleteRes = await serverOps.deletePatches(consumed);
+          if ("error" in deleteRes && deleteRes.error !== undefined) {
             console.error(`Val got an error while cleaning up patches after publish: ${deleteRes.error.message}`);
+          } else if ("errors" in deleteRes && deleteRes.errors !== undefined) {
+            // Per patch, and not fatal: the files are written, so the save
+            // succeeded. A patch left behind is announced again on the next
+            // stat, applies to a base that already contains it, and is removed
+            // then.
+            console.error("Val: could not clean up some patches after publish", deleteRes.errors);
           }
           return {
             status: 200,
-            json: {} // TODO:
+            json: removed.length > 0 ? {
+              removed
+            } : {}
           };
         } else if (serverOps instanceof ValOpsHttp) {
           if (auth.error === undefined && auth.id) {

package/package.json

@@ -16,7 +16,7 @@
     "./package.json": "./package.json"
   },
   "types": "dist/valbuild-server.cjs.d.ts",
-  "version": "0.103.1",
+  "version": "0.103.2",
   "devDependencies": {
     "@prettier/sync": "^0.6.1",
     "@types/jest": "^30.0.0"
@@ -31,7 +31,7 @@
     "zod-validation-error": "^5.0.0",
     "@valbuild/core": "0.103.0",
     "@valbuild/shared": "0.103.0",
-    "@valbuild/ui": "0.103.1"
+    "@valbuild/ui": "0.103.2"
   },
   "engines": {
     "node": ">=18.17.0"