mikser-io 9.25.0 → 9.25.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mikser-io",
-  "version": "9.25.0",
+  "version": "9.25.1",
   "description": "<p align=\"center\">   <img src=\"mikser-lockup-stacked.svg\" alt=\"mikser\" width=\"198\" /> </p>",
   "main": "index.js",
   "exports": {

package/src/catalog.js

@@ -226,6 +226,13 @@ async function applyJournalMutations() {
                     logger.trace('Database %s %s: %s', entity.collection, operation, entity.id)
                     stmtDelete.run(entity.id)
                     // FK ON DELETE CASCADE handles mikser_refs cleanup.
+                    // mikser_failures is cleared explicitly rather than by
+                    // cascade — see manifest.clearFailures for why it cannot
+                    // be a foreign key. Left behind, one row for a deleted
+                    // entity keeps the dispatch set non-empty for the life of
+                    // the database, so layouts' idle-cycle early-out never
+                    // fires again.
+                    runtime.manifest?.clearFailures(entity.id)
                     cacheEvict(entity.id)
                     break
             }

package/src/manifest.js

@@ -297,6 +297,9 @@ export function createManifest(db) {
     const stmtClearFailure = db.prepare(`
         DELETE FROM mikser_failures WHERE id = ? AND destination = ?
     `)
+    const stmtClearFailuresForId = db.prepare(`
+        DELETE FROM mikser_failures WHERE id = ?
+    `)
     const stmtFailuresFor = db.prepare(`
         SELECT id, destination, error, context, firstFailedAt, lastFailedAt, attempts
         FROM mikser_failures WHERE id = ?
@@ -581,6 +584,24 @@ export function createManifest(db) {
             })
         },
 
+        // The entity is gone, so every failure recorded against it is
+        // irrelevant regardless of which destination it was recorded at.
+        //
+        // Deliberately NOT a foreign key with ON DELETE CASCADE, which is how
+        // mikser_refs handles the same situation: a render task's id is not
+        // guaranteed to be a row in mikser_entities — snapshots carry a
+        // `parent` precisely because paginated children render under derived
+        // ids — so an FK would make recordFailure throw from inside the
+        // handler that exists to report a render error, turning a reported
+        // failure into a crash.
+        //
+        // A rename presents as delete + create under a new id, so this covers
+        // that residue too: the old id's rows go with the delete.
+        clearFailures(id) {
+            if (!id) return
+            stmtClearFailuresForId.run(id)
+        },
+
         // A render succeeded, so whatever was recorded about it failing is
         // no longer true. Called on every success, not only after a failure —
         // it is a cheap DELETE and forgetting it would strand the marker.