mikser-io 11.13.0 → 11.14.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mikser-io",
-  "version": "11.13.0",
+  "version": "11.14.1",
   "files": [
     "app.js",
     "index.js",

package/src/instance.js

@@ -31,7 +31,8 @@ import { createHash } from 'node:crypto'
 import { tmpdir } from 'node:os'
 import path from 'node:path'
 import { existsSync, unlinkSync } from 'node:fs'
-import { chmod } from 'node:fs/promises'
+import { chmod, stat } from 'node:fs/promises'
+import { checksum } from './utils/index.js'
 
 import runtime from './runtime.js'
 import { onLoaded } from './lifecycle.js'
@@ -288,23 +289,55 @@ function configMismatch(theirs) {
 // configCoverage lists every local module the config graph pulled in, so a
 // stat over that list catches an edit to an imported module — which a
 // client-side checksum of the entry file would miss entirely.
+// Has a config file CHANGED since this instance started?
+//
+// Content, not mtime. A `git rebase`, `git checkout` or `rsync` rewrites a
+// file with byte-identical content and a new mtime, and the instance then
+// refused every forwarded command — "this instance's config changed on disk
+// since it started" — while `git diff HEAD` reported nothing. Twice in one
+// afternoon on one machine.
+//
+// On production the cost is not a restart. The config checksum is what the
+// cache is stamped with, so a config the engine believes has moved buys a
+// full cold re-derive of every asset, which is how a no-op rebase turns into
+// twenty minutes of ffmpeg.
+//
+// mtime is kept as a PRE-FILTER, not as the answer: it is a stat against a
+// read, and in the ordinary case nothing has moved and nothing is read. Only
+// a file whose mtime shifted gets hashed, and only a file whose CONTENT
+// shifted is reported. A file rewritten identically has its stamp refreshed
+// so the next check is cheap again.
+async function configFingerprint(file) {
+    try {
+        return { mtime: (await stat(file)).mtimeMs, hash: await checksum(file) }
+    } catch {
+        // Deleted, or unreadable. A stable sentinel, so a file that is still
+        // missing on the next check does not read as having changed again.
+        return { mtime: 0, hash: null }
+    }
+}
+
 export async function configStale() {
     const covered = runtime.options.configCoverage?.files ?? []
     if (!covered.length) return null
-    const { stat } = await import('node:fs/promises')
     const stamps = runtime.options.configStamps
     if (!stamps) {
         // First call: record, do not judge. Nothing to compare against yet.
         runtime.options.configStamps = Object.fromEntries(
-            await Promise.all(covered.map(async (file) => {
-                try { return [file, (await stat(file)).mtimeMs] } catch { return [file, 0] }
-            })))
+            await Promise.all(covered.map(async (file) => [file, await configFingerprint(file)])))
         return null
     }
     for (const file of covered) {
-        let now = 0
-        try { now = (await stat(file)).mtimeMs } catch { /* deleted counts as changed */ }
-        if (stamps[file] !== now) return file
+        const was = stamps[file]
+        const now = await configFingerprint(file)
+        if (was?.mtime === now.mtime) continue          // nothing touched it
+        if (was?.hash === now.hash) {
+            // Touched and identical — a checkout, a rebase, a sync. Not a
+            // change, and re-stamped so this file is a stat again next time.
+            stamps[file] = now
+            continue
+        }
+        return file
     }
     return null
 }

package/src/manager.js

@@ -21,12 +21,52 @@ const tasks = []
 // Not done inside runtime.process(): the first cycle's `gated` count is
 // recorded during import, which runs BEFORE process(), so resetting there
 // would wipe it out of a one-shot build's report.
+// File events that arrived while a cycle was running, waiting for it to end.
+//
+// Keyed by nothing and deduplicated by nothing: a file touched three times
+// mid-cycle is three entries, and the source gate collapses them — it compares
+// checksums and skips what has not moved. Deduplicating here would mean
+// deciding that a CREATE and a DELETE for one path cancel out, which they do
+// not.
+const pending = []
+
+// Replay them, now that the cycle is over.
+//
+// Each delivery journals and schedules on its own, exactly as it would have
+// if it had arrived a moment later — which, as far as the engine is now
+// concerned, it did.
+async function flushPending() {
+    if (!pending.length || runtime.processing) return
+    const waiting = pending.splice(0, pending.length)
+    for (const { hook, name, relativePath, fullPath } of waiting) {
+        try {
+            await hook(name, { relativePath })
+        } catch (err) {
+            reportWatchFailure(err, fullPath)
+        }
+    }
+}
+
+// Every cycle ends here, whichever started it — the watcher, `start()`, or a
+// forwarded rebuild — so this is the one place that catches them all.
+//
+// `cycled` and not `onFinalized`: a finalize hook runs INSIDE the cycle, with
+// `runtime.processing` still true, so the flush would defer the events it was
+// called to deliver and the queue would sit there until something unrelated
+// moved. Measured — the first version of this fix did exactly that and
+// imported nothing.
+runtime.hooks.cycled.push(flushPending)
+
 function scheduleProcess() {
     clearTimeout(runtime.engine.processTimeout)
     runtime.engine.processTimeout = setTimeout(async () => {
         await warnConfigStale()
         resetReport()
-        runtime.process()
+        await runtime.process()
+        // A cancelled cycle runs no finalize hooks, so the flush above never
+        // fires for it and anything that arrived mid-cycle would wait for a
+        // later one that may never come.
+        await flushPending()
     }, 1000)
 }
 
@@ -223,6 +263,33 @@ export function watch(name, folder, options = {}) {
     // not the process.
     const deliver = async (hook, fullPath) => {
         const relativePath = fullPath.replace(`${folder}/`, '')
+        // A file that changes WHILE a cycle is running belongs to the next
+        // one, so it waits.
+        //
+        // Delivered immediately, the sync journals the entity behind a cycle
+        // that has already passed its source gate and its dispatch. Later
+        // phases still walk the journal and the catalog is updated, so the
+        // change is half-applied — and then onFinalized clears the journal,
+        // so the next cycle starts with nothing to do and the entity never
+        // renders. No error anywhere; the build is green twice.
+        //
+        // Reported from production, and it is the shape a plugin reaches for
+        // on purpose: one that re-derives pages by touching its sources from
+        // `onProcess`. 47 PDFs touched, every mtime updated, two cycles
+        // completed, not one file re-imported. Worse than a missed rebuild,
+        // because the plugin had already recorded the work as handled — so
+        // nothing retried, and 46 pages served four-day-old prices with
+        // nothing in the log to say so.
+        //
+        // Deferring is the honest reading of what a cycle is: it processes
+        // the state as of its start. The alternative — keeping those journal
+        // entries for the next cycle — does not work, because the engine's
+        // own later walks legitimately consume them first; measured before
+        // choosing this.
+        if (runtime.processing) {
+            pending.push({ hook, name, relativePath, fullPath })
+            return
+        }
         try {
             await hook(name, { relativePath })
         } catch (err) {

package/src/runtime.js

@@ -60,6 +60,11 @@ const runtime = {
         finalized: [],
         sync: [],
         completed: [],
+        // Fires once a cycle is fully over and `processing` is false — see
+        // process(). The watcher uses it to replay file events it held back
+        // while the cycle ran; anything that must act BETWEEN cycles rather
+        // than inside one belongs here.
+        cycled: [],
     },
 
     // What each phase COST, not only what it did.
@@ -190,6 +195,11 @@ const runtime = {
             await this.cancel()
         }
         await this.mutex.use(async () => {
+            // True for the whole cycle, including the gaps between phases —
+            // `phase` goes null between them, so it cannot answer "is a cycle
+            // running". The watcher reads this to decide whether a file event
+            // belongs to this cycle or the next one; see src/manager.js.
+            this.processing = true
             try {
                 this.abortController = new AbortController()
                 const { signal } = this.abortController
@@ -205,8 +215,16 @@ const runtime = {
                 this.phase = 'cancelled'
                 for (let hook of this.hooks.cancelled) await hook()
                 this.phase = null
+            } finally {
+                this.processing = false
             }
         })
+
+        // After the mutex, so `processing` is already false and a hook that
+        // starts work of its own is not told a cycle is still running. Inside
+        // the cycle — at onFinalized, say — it would be, which is exactly the
+        // mistake this placement exists to avoid.
+        for (const hook of this.hooks.cycled) await hook()
     },
 
     async render(signal) {