@stonyx/cron 0.2.1-alpha.6 → 0.2.1-alpha.61

package/README.md

@@ -35,20 +35,79 @@ When a job is executed, its next trigger time is updated, and it is re-inserted
 |  `register`  | `key: string, callback: Function, interval: number, runOnInit?: boolean` | Register a new job with a given interval in seconds. If `runOnInit` is true, the job runs immediately upon registration. |
 | `unregister` |                               `key: string`                              | Remove a previously registered job.                                                                                      |
 
+> **Callback semantics.** Callbacks are invoked fire-and-forget: `Cron` never waits for one to settle, and reschedules a job *before* invoking it. Two *different* jobs that fall due on the same tick may therefore overlap.
+>
+> A job that is still running when it next falls due is skipped — and **keeps** being skipped until that invocation settles. `Cron` provides no timeout by design, so **bounding your own callback is your responsibility**: a promise that never settles means that job never runs again for the lifetime of the process, even though the scheduler stays healthy and the job stays visible in `jobs` and in the heap. Other jobs are unaffected.
+>
+> One warning is emitted per stuck run (not per tick), including how long the invocation has been running. That warning goes to `log.warn` and is **not** gated by `config.cron.log` — a dropped execution reported on a channel a config flag can silence would be indistinguishable from a healthy scheduler.
+>
+> The same-job guarantee holds for the lifetime of a **registration**, not of a key: `unregister` followed by `register` on a key whose invocation is still in flight builds a fresh job object with a fresh guard, so the replacement can run alongside the abandoned invocation. That is also the only way to recover a permanently stuck job.
+>
+> Synchronous throws and asynchronous rejections are both caught and reported through `log.error`, with the error's stack interpolated into the message. Neither can stop the scheduler. Note that a rejection which previously escaped `register()` as an unhandled rejection — process-fatal under Node's default — is now swallowed into `log.error`.
+
 > `MinHeap` is also exported as a public subpath (`@stonyx/cron/min-heap`) and can be imported directly for advanced usage.
 
+## CronService
+
+The default export above is `Cron`: a fire-and-forget interval registry. `@stonyx/cron/service` is a separate, heavier class for jobs that need CRUD, persistence, a run log and error backoff. It is not a drop-in replacement and the two do not share a scheduler.
+
+The two classes agree on the guarantee — the same job is never run concurrently with itself, and different jobs may overlap — but not on the mechanism or on what you can observe. `Cron` invokes callbacks fire-and-forget and reports a skipped run only as an ungated `log.warn` line, one per stuck run, never as a value. `CronService` **awaits** `onJobDue`, its return value shapes `status`/`error`/`summary`, and a refused run comes back to the caller as a value that no log setting can suppress — it is not logged. The two therefore agree on one more thing than the contrast suggests: neither can be made silent by `config.cron.log`.
+
+```js
+import CronService from '@stonyx/cron/service';
+
+const service = new CronService();
+service.onJobDue = async (job) => ({ status: 'ok', summary: 'done' });
+
+await service.start();
+const job = await service.add({ name: 'Nightly', schedule: { kind: 'every', everyMs: 86_400_000 }, payload: { kind: 'agentTurn', message: 'go' } });
+
+const result = await service.run(job.id, 'force');
+```
+
+### The `run()` contract
+
+`run(id, mode)` resolves with an `ExecuteResult`. It **never** invokes the callback twice for one job, and it will refuse rather than queue:
+
+| `status`    | `reason`            | Meaning                                                                        |
+| :---------- | :------------------ | :----------------------------------------------------------------------------- |
+| `'ok'`      | —                   | The callback resolved. `summary` and `durationMs` are set.                     |
+| `'error'`   | —                   | The callback threw or rejected. `error` carries the message; backoff is applied. |
+| `'skipped'` | `'not due'`         | `mode` was `'due'` and the job's next run time has not arrived. Use `'force'` to run anyway. |
+| `'skipped'` | `'already running'`  | A previous invocation of **this** job has not settled. The call is refused, not queued, and nothing is logged. |
+| `'skipped'` | `'removed'`         | The job was removed between the lookup and the claim. The callback did not fire. |
+
+`run()` throws (rather than returning a result) when `id` is not a registered job: `Error: Job not found: <id>`.
+
+**Concurrency.** A job is bounded to one in-flight invocation on every path — manual `run()` and the timer both claim it first. **Different** jobs are not bounded: the callback is deliberately invoked outside the internal lock, so N concurrent `run()` calls on N distinct jobs produce N concurrent callbacks. The scheduler itself never generates that fan-out (its timer path invokes a due batch sequentially); only a caller can. If you drive `run()` from a request handler, bound it on your side. Taking the callback out of the lock is what stops a callback that never settles from blocking `add`/`update`/`remove`; restoring the bound by putting it back would restore that deadlock.
+
+### Breaking changes in this line
+
+Four consumer-visible changes landed with the phase split (#34). All are measured against the emitted `dist/service.d.ts`:
+
+1. **`ExecuteResult.reason` narrowed** from `string` to `'not due' | 'already running' | 'removed'`, and gained the `'removed'` member. Comparing it against a literal outside the union, or `switch`ing on one, is now a compile error (`TS2367` / `TS2678`). Assigning it into `string | undefined` and spreading it are unaffected. The type is exported as `SkipReason`.
+2. **`CronService` is nominally typed.** It carries ECMAScript hard-private members, so the declarations emit `#private;` and a structurally hand-built test double no longer assigns to `CronService` (`TS2741: Property '#private' is missing`). The break is one-directional: `class X extends CronService` still compiles, and assigning a real `CronService` to your own hand-written interface still compiles. **Migration:** declare your own interface and depend on that instead of a `CronService`-typed mock.
+3. **`claimJob`, `settleJob` and `executeClaimed` are not published.** They were never a supported API; a claim taken without its matching settle strands the job permanently.
+4. **`run()` no longer serializes across jobs** — see the concurrency note above.
+
+`SkipReason`, `ExecuteResult`, `JobDueResult`, `ServiceStatus`, `ListOptions` and `OnJobDueCallback` are all exported from `@stonyx/cron/service`, so an exhaustive handler over `reason` is expressible.
+
 ## Configuration
 
-Optionally, logging and debugging can be enabled through `config.cron`:
+Optionally, informational logging and debugging can be controlled through `config.cron`:
 
 ```js
 config.cron = {
-  log: true // enable cron job logs
+  log: true // informational cron job logs; defaults to true
 };
 
 config.debug = true; // optional: debug logs for job registration and execution
 ```
 
+`config.cron.log` gates **informational** messages only. Error reports and the
+stuck-job warning described above are never gated by it, so setting it to `false`
+cannot make a dropped execution silent.
+
 ## License
 
 Apache — do what you want, just keep attribution.

package/dist/main.d.ts

@@ -3,6 +3,24 @@ interface CronJob extends HeapItem {
     callback: () => void | Promise<void>;
     interval: string;
     key: string;
+    /**
+     * Timestamp (ms) at which the current invocation started; `undefined` when the
+     * job is idle. Optional so the emitted `CronJob` stays assignable from a job
+     * object built by a consumer — `jobs`, `heap` and `setNextTrigger` all expose
+     * this interface structurally, so a required field is a breaking type change.
+     *
+     * A timestamp rather than a boolean, mirroring `job.state.runningAtMs` in the
+     * service tier (`markRunning` / `applyResult` / `isDue` in `src/job.ts`), and
+     * carrying the one fact a stuck-job warning needs: how long it has been stuck.
+     * `CronService.running` is a class-level re-entrancy flag and a different
+     * concept; reusing that word here would collide.
+     */
+    runningAtMs?: number;
+    /**
+     * True once a skip has been reported for the *current* invocation. Bounds the
+     * still-running warning to one line per stuck run instead of one per tick.
+     */
+    skipReported?: boolean;
 }
 export default class Cron {
     static instance: Cron | null;
@@ -10,10 +28,38 @@ export default class Cron {
     heap: MinHeap<CronJob>;
     timer: ReturnType<typeof setTimeout> | null;
     constructor();
+    init(): Promise<void>;
     scheduleNextRun(): void;
     runDueJobs(): Promise<void>;
     register(key: string, callback: () => void | Promise<void>, interval: string, runOnInit?: boolean): void;
     unregister(key: string): void;
+    /**
+     * The one place this class invokes a consumer callback.
+     *
+     * Never blocks the caller, catches synchronous throws and asynchronous
+     * rejections identically, and skips the invocation entirely while the job's
+     * previous invocation has not settled (fire-and-forget would otherwise let a
+     * slow job stack invocations on itself).
+     *
+     * Everything that touches the callback — including the thenable probe and the
+     * handler attachment — is inside the `try`. A callback may return an object
+     * whose `then` is a throwing getter, and reading it outside the guard would
+     * abort the drain loop before `scheduleNextRun()`, which is defect #36 again.
+     */
+    invokeJob(job: CronJob, runOnInit?: boolean): void;
+    /**
+     * Report a scheduler-level message without ever letting the logger's own
+     * failure reach the caller.
+     *
+     * `@stonyx/logs` convenience methods return a promise and write to disk
+     * through an unguarded `mkdirSync` + `fsp.appendFile`. On a read-only or full
+     * log volume that promise rejects; an unobserved rejection raised from inside
+     * the handler that exists to prevent unhandled rejections would re-create
+     * exactly the defect this class was fixed for.
+     */
+    report(level: 'error' | 'warn', message: string): void;
+    /** Release a job's in-flight guard. Only ever called for the job it belongs to. */
+    release(job: CronJob): void;
     setNextTrigger(job: CronJob): void;
     log(text: string, key?: string | null): void;
 }

package/dist/main.js

@@ -17,6 +17,68 @@ import config from 'stonyx/config';
 import log from 'stonyx/log';
 import { getTimestamp } from '@stonyx/utils/date';
 import MinHeap from './min-heap.js';
+/** Longest error text that may reach a log line. Anything past this is truncated. */
+const MAX_LOGGED_ERROR_LENGTH = 512;
+/**
+ * Flatten a value for interpolation into a single log line.
+ *
+ * `@stonyx/logs` writes `${timestamp} ${content}\n` to a newline-delimited
+ * file, so any `\r` or `\n` inside `content` ends the record early and
+ * everything after it is read back as a separate entry — including a forged
+ * `[timestamp] ...` prefix that is indistinguishable from a real one. Newlines
+ * become the literal two characters so the content survives for a reader, and
+ * the length cap keeps one pathological value from swamping the file.
+ *
+ * Kept byte-identical to the `forLog` landing in `src/service.ts` on #34: the
+ * two tiers render the same untrusted values into the same log file, and a
+ * reader diagnosing a forged record should not have to know which tier wrote
+ * it. Duplicated rather than shared because the two land on separate branches;
+ * folding them into one helper is a follow-up once both are on `dev`, not a
+ * cross-PR dependency that would make either unmergeable alone.
+ */
+function forLog(value, maxLength) {
+    const flattened = value.replace(/\r\n|[\r\n\u2028\u2029]/g, '\\n');
+    return flattened.length > maxLength ? `${flattened.slice(0, maxLength)}...` : flattened;
+}
+/**
+ * Render an unknown thrown value as log text. Total by construction.
+ *
+ * `@stonyx/logs` reads a second argument as `logToFile`, not as a format
+ * argument, so `log.error(message, err)` discards the error entirely *and*
+ * forces a disk write on every failure. The error has to be interpolated into
+ * the message instead — the shape `CronService.executeJob` already uses.
+ *
+ * Every read below touches a consumer-controlled value and can therefore throw:
+ * `instanceof` runs a proxy's `getPrototypeOf` trap, `stack`/`name`/`message`
+ * can be accessor properties, and `String(Object.create(null))` throws outright.
+ * This function runs *inside* `invokeJob`'s catch — the one place whose job is
+ * to stop a callback failure from reaching the scheduler — so a throw here
+ * escapes that catch and skips `scheduleNextRun()`, which is defect #36.
+ */
+function describeError(err) {
+    try {
+        if (err instanceof Error) {
+            return forLog(err.stack ?? `${err.name}: ${err.message}`, MAX_LOGGED_ERROR_LENGTH);
+        }
+        return forLog(String(err), MAX_LOGGED_ERROR_LENGTH);
+    }
+    catch {
+        // Deliberately not re-entrant: describing the failure to describe the error
+        // would be the same read that just threw.
+        return '<thrown value could not be rendered>';
+    }
+}
+/**
+ * Render a consumer-supplied job key safely for log output.
+ *
+ * Keys reach the log verbatim, so a key containing a newline can forge a
+ * complete, well-formed log line (`'a:\n[FORGED] Cron::admin - all jobs
+ * healthy'`). `JSON.stringify` quotes the value and escapes the control
+ * characters, which is also how the key is rendered one tier up.
+ */
+function describeKey(key) {
+    return JSON.stringify(key);
+}
 export default class Cron {
     static instance;
     jobs = {};
@@ -27,6 +89,12 @@ export default class Cron {
             return Cron.instance;
         Cron.instance = this;
     }
+    async init() {
+        // Self-register so log.cron works even when @stonyx/cron is in the
+        // consumer's `dependencies` (stonyx loader only merges devDependencies).
+        const { logColor = '#888', logMethod = 'cron' } = config.cron ?? {};
+        log.defineType(logMethod, logColor);
+    }
     scheduleNextRun() {
         if (this.timer)
             clearTimeout(this.timer);
@@ -37,28 +105,41 @@ export default class Cron {
         if (!nextJob)
             return;
         const delay = Math.max(0, nextJob.nextTrigger - getTimestamp()) * 1000;
-        this.timer = setTimeout(() => this.runDueJobs(), delay);
+        // Terminal catch: `runDueJobs` is async, so anything that escapes it would
+        // otherwise become an unhandled rejection raised from a bare timer callback
+        // — the very failure mode this class was fixed for.
+        this.timer = setTimeout(() => {
+            this.runDueJobs().catch((err) => {
+                this.report('error', `Cron scheduler tick failed: ${describeError(err)}`);
+            });
+        }, delay);
     }
     async runDueJobs() {
         const now = getTimestamp();
         const { heap } = this;
-        while (!heap.isEmpty()) {
-            const next = heap.peek();
-            if (!next || next.nextTrigger > now)
-                break;
-            const job = heap.pop();
-            if (config.debug)
-                this.log('job has been triggered', job.key);
-            try {
-                await job.callback();
+        // `finally`, not a trailing statement: `scheduleNextRun()` running on every
+        // exit from the drain loop is the invariant this whole fix is about. If
+        // anything in the loop body ever throws, the scheduler must still re-arm
+        // rather than stopping silently while `timer` still holds a fired handle.
+        try {
+            while (!heap.isEmpty()) {
+                const next = heap.peek();
+                if (!next || next.nextTrigger > now)
+                    break;
+                const job = heap.pop();
+                if (config.debug)
+                    this.log('job has been triggered', job.key);
+                // Reschedule before invoking: a consumer callback is never awaited here,
+                // so a callback that hangs or rejects can no longer starve the drain loop
+                // or leave the job orphaned outside the heap.
+                this.setNextTrigger(job);
+                heap.push(job);
+                this.invokeJob(job);
             }
-            catch (err) {
-                log.error(`Cron job "${job.key}" failed:`, err);
-            }
-            this.setNextTrigger(job);
-            heap.push(job);
         }
-        this.scheduleNextRun();
+        finally {
+            this.scheduleNextRun();
+        }
     }
     register(key, callback, interval, runOnInit = false) {
         const job = { callback, interval, key, nextTrigger: 0 };
@@ -68,15 +149,18 @@ export default class Cron {
         if (config.debug) {
             this.log(`job has been registered with interval: ${interval}`, key);
         }
-        if (runOnInit) {
-            try {
-                callback();
-            }
-            catch (err) {
-                log.error(`Cron job "${key}" failed on init:`, err);
-            }
+        // `finally`, not a trailing statement, for the same reason as `runDueJobs`:
+        // a job that is registered but never scheduled is defect #36's terminal
+        // state reached through the other entry point. `invokeJob` is total, so
+        // this guard should be unreachable — which is exactly why it is a guard and
+        // not an assumption.
+        try {
+            if (runOnInit)
+                this.invokeJob(job, true);
+        }
+        finally {
+            this.scheduleNextRun();
         }
-        this.scheduleNextRun();
     }
     unregister(key) {
         const { heap, jobs } = this;
@@ -89,13 +173,104 @@ export default class Cron {
             this.log('job has been unregistered', key);
         this.scheduleNextRun();
     }
+    /**
+     * The one place this class invokes a consumer callback.
+     *
+     * Never blocks the caller, catches synchronous throws and asynchronous
+     * rejections identically, and skips the invocation entirely while the job's
+     * previous invocation has not settled (fire-and-forget would otherwise let a
+     * slow job stack invocations on itself).
+     *
+     * Everything that touches the callback — including the thenable probe and the
+     * handler attachment — is inside the `try`. A callback may return an object
+     * whose `then` is a throwing getter, and reading it outside the guard would
+     * abort the drain loop before `scheduleNextRun()`, which is defect #36 again.
+     */
+    invokeJob(job, runOnInit = false) {
+        const { key } = job;
+        const context = runOnInit ? 'failed on init:' : 'failed:';
+        // The in-flight guard lives on the job object, not in a module-level set
+        // keyed by string. Object identity is invocation identity: the only thing
+        // that clears the guard is the settle handler of the invocation that set it,
+        // and that handler closes over this exact job object, so a stale handler can
+        // never release a later invocation's guard.
+        if (job.runningAtMs !== undefined) {
+            // Bounded to one line per stuck run, not one per tick. A permanently hung
+            // job is re-pushed and re-skipped every interval forever; at the 1s
+            // interval this class's own tests use that measures 43,200 lines/day per
+            // job — a disk-fill and ingest-cost vector whose natural operator response
+            // is to silence the only signal that the job is dead.
+            if (!job.skipReported) {
+                job.skipReported = true;
+                const runningForSeconds = Math.max(0, Math.round((Date.now() - job.runningAtMs) / 1000));
+                // Ungated, deliberately, matching the sibling `CronService` handler. A
+                // skipped run is a *lost* execution, and `runDueJobs`/`register` both
+                // return `void`, so this is the legacy class's only wedged-job channel.
+                // Routing it through `this.log` would put it behind `config.cron.log`,
+                // where a permanently dead job is indistinguishable from a healthy one.
+                this.report('warn', `Cron job ${describeKey(key)} is still running after ${runningForSeconds}s; skipping this `
+                    + 'tick and any further ticks until it settles (this warning is not repeated for this run)');
+            }
+            return;
+        }
+        job.runningAtMs = Date.now();
+        job.skipReported = false;
+        try {
+            const result = job.callback();
+            if (result && typeof result.then === 'function') {
+                Promise.resolve(result)
+                    .catch((err) => {
+                    // Braces matter: returning `report`'s value would put it back into
+                    // the chain, and `.finally` passes a rejection straight through.
+                    this.report('error', `Cron job ${describeKey(key)} ${context} ${describeError(err)}`);
+                })
+                    .finally(() => { this.release(job); })
+                    // Backstop: a throw inside the error handler or the release must not
+                    // re-create the unhandled rejection this helper exists to prevent.
+                    .catch(() => { });
+                return;
+            }
+            this.release(job);
+        }
+        catch (err) {
+            this.release(job);
+            this.report('error', `Cron job ${describeKey(key)} ${context} ${describeError(err)}`);
+        }
+    }
+    /**
+     * Report a scheduler-level message without ever letting the logger's own
+     * failure reach the caller.
+     *
+     * `@stonyx/logs` convenience methods return a promise and write to disk
+     * through an unguarded `mkdirSync` + `fsp.appendFile`. On a read-only or full
+     * log volume that promise rejects; an unobserved rejection raised from inside
+     * the handler that exists to prevent unhandled rejections would re-create
+     * exactly the defect this class was fixed for.
+     */
+    report(level, message) {
+        try {
+            const result = level === 'error' ? log.error(message) : log.warn(message);
+            void Promise.resolve(result).catch(() => { });
+        }
+        catch {
+            // Nowhere left to report to; the logger must never stop the scheduler.
+        }
+    }
+    /** Release a job's in-flight guard. Only ever called for the job it belongs to. */
+    release(job) {
+        job.runningAtMs = undefined;
+        job.skipReported = false;
+    }
     setNextTrigger(job) {
         job.nextTrigger = getTimestamp() + parseInt(job.interval, 10);
     }
     log(text, key = null) {
         if (!config.cron?.log)
             return;
-        const tag = key ? `Cron::${key}` : `Cron`;
+        // The key is consumer-controlled and reaches the log verbatim. Strip the
+        // line terminators so a key cannot forge a second, well-formed log line;
+        // the surrounding format is unchanged.
+        const tag = key ? `Cron::${key.replace(/[\r\n]+/g, ' ')}` : `Cron`;
         log.cron(`${tag} - ${text}:`);
     }
 }

package/dist/service.d.ts

@@ -4,29 +4,37 @@ import RunLog from './run-log.js';
 interface HeapEntry extends HeapItem {
     key: string;
 }
-interface JobDueResult {
+/**
+ * Why a `run()` did not invoke the callback. Exported so a consumer can write a
+ * total handler over it: the union is closed and narrowed (it was `string`
+ * before #34), so an exhaustive `switch` is now both possible and expected.
+ */
+export type SkipReason = 'not due' | 'already running' | 'removed';
+export interface JobDueResult {
     status?: string;
     error?: string;
     summary?: string;
 }
-interface ExecuteResult {
+export interface ExecuteResult {
     status: string;
     error?: string;
     summary?: string;
     durationMs?: number;
     deleted?: boolean;
-    reason?: string;
+    /** Only set when `status` is `'skipped'`. */
+    reason?: SkipReason;
 }
-interface ServiceStatus {
+export interface ServiceStatus {
     started: boolean;
     jobCount: number;
     nextWakeAtMs: number | undefined;
 }
-interface ListOptions {
+export interface ListOptions {
     includeDisabled?: boolean;
 }
-type OnJobDueCallback = (job: Job) => Promise<JobDueResult | void> | JobDueResult | void;
+export type OnJobDueCallback = (job: Job) => Promise<JobDueResult | void> | JobDueResult | void;
 export default class CronService {
+    #private;
     jobs: Map<string, Job>;
     heap: MinHeap<HeapEntry>;
     timer: ReturnType<typeof setTimeout> | null;
@@ -36,7 +44,38 @@ export default class CronService {
     onJobDue: OnJobDueCallback | null;
     constructor();
     /**
-     * Start the service. Loads jobs from store (if any), arms timer.
+     * Start the service. Loads jobs from store (if any), arms timer. A no-op if
+     * already started.
+     *
+     * `initialJobs` crosses a serialization boundary — it is whatever the
+     * consumer's store handed back — so `Job[]` is a compile-time claim about
+     * runtime data. Three behaviours follow from that and are worth knowing
+     * before you call this, because all three are deliberate and two of them
+     * differ from a plain "load and arm":
+     *
+     * 1. WRITES TO `row.state`. A STALE claim (`state.runningAtMs` set by a
+     *    process that is gone) is released, because nothing else ever will —
+     *    there is no lease on the field (#35) — and left in place it is a job
+     *    that is dead forever while `status()` reports it healthy. A LIVE claim,
+     *    held by an invocation still running in this process, is left alone:
+     *    releasing it would let the timer start a second concurrent invocation of
+     *    a job that is already running.
+     *
+     * 2. THROWS on a row this class cannot use, rather than accepting it. A row
+     *    whose `state` is missing, or frozen (`structuredClone` + `Object.freeze`
+     *    is an ordinary defensive rehydration), throws out of `start()` where the
+     *    caller's own `await` can catch it. The alternative is a `TypeError` from
+     *    inside a bare timer callback later — an unhandled rejection, and
+     *    process-fatal under Node's default.
+     *
+     * 3. ARMS THE TIMER EVEN IF IT THROWS. The rows loaded before the throw are
+     *    registered and scheduled. Without this, a throw leaves `started: true`
+     *    (so a retry is a no-op) with jobs in the heap and no timer: nothing ever
+     *    fires and `status()` still reports healthy.
+     *
+     * Hand it deserialized rows and all three are invisible. Hand it live `Job`
+     * objects this service is currently executing and only 1 is observable, by
+     * design.
      */
     start(initialJobs?: Job[]): Promise<void>;
     /**
@@ -69,6 +108,37 @@ export default class CronService {
     remove(id: string): Promise<void>;
     /**
      * Manually trigger a job.
+     *
+     * Returns `{ status: 'skipped', reason }` without invoking the callback when
+     * the job is not due (`mode: 'due'`), is already in flight
+     * (`'already running'`), or was removed before the claim landed
+     * (`'removed'`). Before the phase split, a forced run against an in-flight
+     * job launched a second concurrent invocation.
+     *
+     * THROWS (rather than returning a skip) when `id` is not a registered job:
+     * `Error("Job not found: <id>")`. A job that disappears between this lookup
+     * and the claim is the `'removed'` skip above, not a throw — the two differ
+     * only by the timing of a race, and the second is a legitimate outcome
+     * whereas the first is a caller error.
+     *
+     * CONCURRENCY: the same job is bounded to one in-flight invocation on every
+     * path, and the timer path invokes due jobs one at a time. `run()` fan-out
+     * across DIFFERENT jobs is deliberately unbounded — N concurrent `run()`
+     * calls produce N concurrent consumer callbacks. Before the phase split
+     * these serialized behind the module-global lock; that serialization was the
+     * bug rather than the feature (one hung callback wedged every other caller),
+     * so it is not restored here. The fan-out is caller-driven and the scheduler
+     * never produces it on its own. A per-invoke bound belongs above this layer;
+     * it is tracked on stonyx-cron#35 alongside the execution timeout.
+     *
+     * NOT FIXED HERE: the phase split fixes the LOCK wedge, not the TIMER. A
+     * callback that never settles still stops `onTimer`'s sequential loop
+     * forever — `running` stays true, every later tick early-returns and re-arms,
+     * and the hung job's batch siblings stay claimed and off-heap having never
+     * been invoked. CRUD still resolves and `status()` still reports
+     * `started: true`, so that failure is now silent where it used to be loud.
+     * Bounding the callback and releasing batch siblings is stonyx-cron#35. Do
+     * not read this method's doc as "the hang is fixed".
      */
     run(id: string, mode?: 'due' | 'force'): Promise<ExecuteResult>;
     /**
@@ -78,6 +148,25 @@ export default class CronService {
     armTimer(): void;
     onTimer(): Promise<void>;
     findDueJobs(nowMs: number): Job[];
+    /**
+     * Execute a job in three phases:
+     *
+     *   1. claim  (locked)   — take ownership of the job, detach it from the heap
+     *   2. invoke (UNLOCKED) — await the consumer callback
+     *   3. settle (locked)   — apply the result, log it, re-insert into the heap
+     *
+     * The critical section deliberately excludes phase 2. `onJobDue` is
+     * arbitrary, unbounded consumer code; awaiting it under the module-global
+     * lock is what wedged every subsequent `locked()` call (add/update/remove)
+     * when a callback never settled.
+     *
+     * `onTimer` performs the batch claim (`findDueJobs` + `markRunning`) for all
+     * due jobs under a single lock and then enters at phase 2 via
+     * `#executeClaimed`. That entry point is `#private` rather than a parameter
+     * on this method: as a published `alreadyClaimed` flag it would be a
+     * supported way to skip phase 1 entirely, defeating the claim guard and
+     * allowing concurrent `onJobDue` invocations for the same job.
+     */
     executeJob(job: Job): Promise<ExecuteResult>;
     removeFromHeap(id: string): void;
     log(message: string): void;

package/dist/service.js

@@ -2,7 +2,21 @@
  * CronService - the main API for advanced job scheduling.
  *
  * Manages jobs in memory with a min-heap for efficient next-job lookup.
- * All state mutations are serialized via async locking.
+ *
+ * Async locking, but never around the consumer callback. Execution is split
+ * into three phases: claim (locked), invoke (UNLOCKED), settle (locked). Only
+ * phases 1 and 3 are serialized; the critical section deliberately excludes
+ * phase 2, so a consumer callback that never settles cannot wedge the lock
+ * chain and block add/update/remove. See `run()` and `#executeClaimed`.
+ *
+ * CONSUMER NOTE — this class is NOMINALLY typed. It carries ECMAScript hard-
+ * private members, so `dist/service.d.ts` emits `#private;` on the class and a
+ * structurally-built test double will not assign to `CronService`
+ * (`TS2741: Property '#private' is missing`). The break is one-directional and
+ * has a zero-cost workaround: `extends CronService` still compiles, and
+ * assigning a real `CronService` to your own hand-written interface still
+ * compiles. Declare your own interface and depend on that rather than
+ * hand-building a `CronService`-typed mock. See README's `CronService` section.
  */
 import config from 'stonyx/config';
 import log from 'stonyx/log';
@@ -12,6 +26,121 @@ import { locked } from './locked.js';
 import { normalizeJobInput, recoverFlatParams } from './normalize.js';
 import RunLog from './run-log.js';
 const MAX_TIMER_DELAY_MS = 60_000;
+/** Longest error text that may reach a log line. Anything past this is truncated. */
+const MAX_LOGGED_ERROR_LENGTH = 512;
+/** Longest job name that may reach a log line. Anything past this is truncated. */
+const MAX_LOGGED_NAME_LENGTH = 120;
+/**
+ * Flatten a value for interpolation into a single log line.
+ *
+ * Chronicle writes `${timestamp} ${content}\n` to a newline-delimited file, so
+ * any `\r` or `\n` inside `content` ends the record early and everything after
+ * it is read back as a separate, attacker-shaped entry — including a forged
+ * `[timestamp] Cron — ...` prefix that is indistinguishable from a real one.
+ * Both values that reach these lines are untrusted: `job.name` is passed
+ * through `createJob` unvalidated and `normalize.ts` exists specifically to
+ * accept AI-shaped input, and an error message is arbitrary consumer-callback
+ * text. Newlines become the literal two characters so the content survives for
+ * a reader, and the length cap keeps one pathological value from swamping the
+ * file.
+ *
+ * TOTAL, for the same reason `describeError` below is total, and the parameter
+ * is coerced even though it is typed `string`. `job.name` is typed `string` but
+ * that is a compile-time claim about runtime data: `normalize.ts` only
+ * GENERATES a name when the field is falsy, so `add({ name: 12345 })` stores a
+ * number through the public API, and `start(initialJobs)` takes names verbatim
+ * from the consumer's store \u2014 the same untrusted boundary `start()` already
+ * hardens `state` against.
+ *
+ * Fixed HERE rather than by coercing in `normalize`, deliberately. Coercing at
+ * `normalize` closes the `add()` path only; the rehydration path bypasses both
+ * `normalize` and `createJob` entirely, and that is the path this class already
+ * treats as hostile. And this helper is on the ERROR path \u2014 a helper that
+ * throws while building an error report destroys the report it exists to
+ * produce. Measured pre-fix: `run()` rejected with `TypeError: value.replace is
+ * not a function` instead of returning an `ExecuteResult`, and on the timer
+ * path the failure record was swallowed entirely (0 records for a job that
+ * failed) because the throw happened inside the reporter's own `try`.
+ *
+ * `String(value)` alone is NOT enough: a value whose `toString` or
+ * `Symbol.toPrimitive` throws raises out of the coercion itself, so the `try`
+ * is load-bearing and not belt-and-braces. Kept typed `string` rather than
+ * widened to `unknown` so call sites still get compile-time pressure; the
+ * runtime coercion is the defence, not the signature.
+ */
+function forLog(value, maxLength) {
+    let flattened;
+    try {
+        flattened = String(value).replace(/\r\n|[\r\n\u2028\u2029]/g, '\\n');
+    }
+    catch {
+        return '<unrenderable value>';
+    }
+    return flattened.length > maxLength ? `${flattened.slice(0, maxLength)}...` : flattened;
+}
+/**
+ * Describe a thrown value without ever throwing.
+ *
+ * `String(err)` is not total: a null-prototype object, or any object whose
+ * `toString`/`Symbol.toPrimitive` throws, raises "Cannot convert object to
+ * primitive value". Consumer callbacks throw arbitrary values, so the error
+ * handler must not become a second failure source of its own.
+ *
+ * The `instanceof Error` branch needs the same guard as the other one. `Error`
+ * is subclassable and `message` is a plain writable property, so a consumer can
+ * hand back an `Error` whose `message` is a getter that throws, or one that is
+ * an object whose `toString` throws — `Error.prototype.message` is typed
+ * `string`, so TypeScript sees nothing wrong and the coercion is deferred to
+ * the caller's template literal, outside every guard here. That made `run()`
+ * reject instead of returning an `ExecuteResult`: a contract violation in the
+ * function written to prevent exactly that. Reading and coercing `message`
+ * inside the `try` is what closes it.
+ *
+ * `Cron` in `main.ts` carries its own `describeError` and the two deliberately
+ * differ: it renders for a log line only, so it prefers `err.stack`; this one
+ * is also returned to the caller as `ExecuteResult.error` and persisted in a
+ * per-job run log, where a stack would be an unbounded blob in every stored
+ * failure. Recorded in `docs/architecture.md` under Code Patterns &
+ * Conventions -> Private Members -> "Two `describeError` helpers, deliberately
+ * not shared (#34 / #36)" — do not merge them into a shared helper without
+ * reading that first. NOT the `### Error Handling` section further down, which
+ * is about the legacy `Cron` and does not carry this decision.
+ */
+function describeError(err) {
+    try {
+        return err instanceof Error ? String(err.message) : String(err);
+    }
+    catch {
+        return 'unknown error';
+    }
+}
+/**
+ * Job objects whose claim is held by an invocation still running IN THIS
+ * PROCESS. Added by phase 1, removed by phase 3 (or by the one hand-release in
+ * `#executeClaimed`), so membership is exactly "a settle is still coming".
+ *
+ * This exists so `start()` can tell a STALE claim from a LIVE one. Both look
+ * identical in `job.state.runningAtMs` — a number — but they need opposite
+ * treatment: a stale claim must be released (it is #34's permanently-dead job,
+ * and nothing reaps it) while a live one must be left alone (releasing it lets
+ * the timer launch a second concurrent invocation of a job that is already
+ * running, breaking the one invariant this class advertises).
+ *
+ * Keyed on the Job OBJECT, not the id, and module-level rather than per
+ * instance, for the two reasons that make those the only workable choices:
+ *
+ *   - Object identity is what makes it correct across `CronService` instances.
+ *     A second service handed live rows sees the same objects, so it inherits
+ *     the answer rather than guessing; a per-instance set would report "not in
+ *     flight" for a claim a sibling instance is holding. `locked()`'s chain is
+ *     already module-global for the same reason.
+ *   - Identity is also what makes it correct after a real crash. A restart
+ *     deserializes its rows, so those are new objects and are never members —
+ *     the #34 release still fires, which is the whole point of it.
+ *
+ * `WeakSet`, so a job that is removed and dropped mid-flight is not retained.
+ */
+const inFlight = new WeakSet();
 export default class CronService {
     jobs;
     heap;
@@ -32,21 +161,114 @@ export default class CronService {
     }
     // -- Lifecycle -------------------------------------------------------
     /**
-     * Start the service. Loads jobs from store (if any), arms timer.
+     * Start the service. Loads jobs from store (if any), arms timer. A no-op if
+     * already started.
+     *
+     * `initialJobs` crosses a serialization boundary — it is whatever the
+     * consumer's store handed back — so `Job[]` is a compile-time claim about
+     * runtime data. Three behaviours follow from that and are worth knowing
+     * before you call this, because all three are deliberate and two of them
+     * differ from a plain "load and arm":
+     *
+     * 1. WRITES TO `row.state`. A STALE claim (`state.runningAtMs` set by a
+     *    process that is gone) is released, because nothing else ever will —
+     *    there is no lease on the field (#35) — and left in place it is a job
+     *    that is dead forever while `status()` reports it healthy. A LIVE claim,
+     *    held by an invocation still running in this process, is left alone:
+     *    releasing it would let the timer start a second concurrent invocation of
+     *    a job that is already running.
+     *
+     * 2. THROWS on a row this class cannot use, rather than accepting it. A row
+     *    whose `state` is missing, or frozen (`structuredClone` + `Object.freeze`
+     *    is an ordinary defensive rehydration), throws out of `start()` where the
+     *    caller's own `await` can catch it. The alternative is a `TypeError` from
+     *    inside a bare timer callback later — an unhandled rejection, and
+     *    process-fatal under Node's default.
+     *
+     * 3. ARMS THE TIMER EVEN IF IT THROWS. The rows loaded before the throw are
+     *    registered and scheduled. Without this, a throw leaves `started: true`
+     *    (so a retry is a no-op) with jobs in the heap and no timer: nothing ever
+     *    fires and `status()` still reports healthy.
+     *
+     * Hand it deserialized rows and all three are invisible. Hand it live `Job`
+     * objects this service is currently executing and only 1 is observable, by
+     * design.
      */
     async start(initialJobs) {
         if (this.started)
             return;
         this.started = true;
-        if (initialJobs) {
-            for (const job of initialJobs) {
-                this.jobs.set(job.id, job);
-                if (job.enabled && job.state.nextRunAtMs) {
-                    this.heap.push({ key: job.id, nextTrigger: job.state.nextRunAtMs });
+        // `finally`, not a trailing statement. Reconciled with the same guard #53
+        // puts around `register`'s `runOnInit` invocation: a scheduler that is
+        // marked started but never armed is the terminal state both fixes exist to
+        // remove, reached here through the other entry point. `initialJobs` crosses
+        // a serialization boundary — it is whatever the consumer's store handed
+        // back — so `Job[]` is a compile-time claim about runtime data, and a row
+        // missing `state` throws mid-loop. Without this, `start()` leaves
+        // `started: true` (so it is now a no-op), the rows registered before the
+        // throw sitting in the heap, and NO timer: measured, `status()` then
+        // reports `{ started: true, jobCount: 1, nextWakeAtMs: <real> }` while
+        // nothing will ever fire. Silent and healthy-looking, again.
+        try {
+            if (initialJobs) {
+                for (const job of initialJobs) {
+                    // A STALE `runningAtMs` records a claim taken by a process that is
+                    // gone. Nothing will ever settle it, and nothing reaps it — there is
+                    // no lease on the field (tracked on #35). Left in place it is a
+                    // permanently dead job that still reports healthy: `isDue` returns
+                    // false forever because of the flag, `run()` answers
+                    // `'already running'` forever, `update()` never touches
+                    // `state.runningAtMs`, and `status()` counts it like any other. The
+                    // consumer's only recovery would be remove() + add(), losing the job
+                    // id and its run history.
+                    //
+                    // Same hazard, same treatment as the hand-release on the `'removed'`
+                    // path in `#executeClaimed`: a claim with no reachable settle must be
+                    // released. Assigned directly rather than via `applyResult` for the same
+                    // reason — this releases the claim and nothing else. The job did not
+                    // run, so it gets no run-log row, no `lastStatus`, and no recomputed
+                    // `nextRunAtMs`; it is rescheduled from the store's own value below.
+                    //
+                    // But NOT every `runningAtMs` here is stale, and the field cannot
+                    // tell you which — it is a number either way. `start()` early-returns
+                    // when `started`, so reaching this with a LIVE claim needs `stop()`
+                    // then `start(sameObjects)` (an in-process restart against a store
+                    // that hands back references rather than fresh rows) or a second
+                    // `CronService` handed live rows. Measured on the unconditional
+                    // version: the release cleared a live claim, the timer then found the
+                    // job due, and one job got TWO concurrent in-flight callbacks. That
+                    // is the single invariant this class advertises and that #34/#35
+                    // exist to protect, so the release is guarded on `inFlight` —
+                    // authoritative object identity, not a heuristic on the timestamp.
+                    // See `inFlight`'s docblock for why identity is also what keeps the
+                    // stale case working after a real crash.
+                    //
+                    // The guard is deliberately NOT a `job.state.runningAtMs` read.
+                    // Guarding on THAT makes `start()` accept a row whose `state` is
+                    // frozen — `structuredClone` + `Object.freeze` is an ordinary
+                    // defensive rehydration — and that row is not usable by this class at
+                    // all: `markRunning` writes the same field on every execution.
+                    // Measured, that guard moves the failure from a throw out of
+                    // `start()`, which the consumer's own `await` can catch, to a
+                    // TypeError raised inside `onTimer`'s batch claim — a bare timer
+                    // callback, so it surfaces as an unhandled rejection and is
+                    // process-fatal under Node's default. `inFlight` does not have that
+                    // problem: a deserialized row is never a member, so the write still
+                    // happens and the frozen row still fails loudly at the boundary. Both
+                    // properties are tested; do not collapse the two guards into one.
+                    if (!inFlight.has(job)) {
+                        job.state.runningAtMs = undefined;
+                    }
+                    this.jobs.set(job.id, job);
+                    if (job.enabled && job.state.nextRunAtMs) {
+                        this.heap.push({ key: job.id, nextTrigger: job.state.nextRunAtMs });
+                    }
                 }
             }
         }
-        this.armTimer();
+        finally {
+            this.armTimer();
+        }
     }
     /**
      * Stop the service. Clears timer.
@@ -136,6 +358,37 @@ export default class CronService {
     }
     /**
      * Manually trigger a job.
+     *
+     * Returns `{ status: 'skipped', reason }` without invoking the callback when
+     * the job is not due (`mode: 'due'`), is already in flight
+     * (`'already running'`), or was removed before the claim landed
+     * (`'removed'`). Before the phase split, a forced run against an in-flight
+     * job launched a second concurrent invocation.
+     *
+     * THROWS (rather than returning a skip) when `id` is not a registered job:
+     * `Error("Job not found: <id>")`. A job that disappears between this lookup
+     * and the claim is the `'removed'` skip above, not a throw — the two differ
+     * only by the timing of a race, and the second is a legitimate outcome
+     * whereas the first is a caller error.
+     *
+     * CONCURRENCY: the same job is bounded to one in-flight invocation on every
+     * path, and the timer path invokes due jobs one at a time. `run()` fan-out
+     * across DIFFERENT jobs is deliberately unbounded — N concurrent `run()`
+     * calls produce N concurrent consumer callbacks. Before the phase split
+     * these serialized behind the module-global lock; that serialization was the
+     * bug rather than the feature (one hung callback wedged every other caller),
+     * so it is not restored here. The fan-out is caller-driven and the scheduler
+     * never produces it on its own. A per-invoke bound belongs above this layer;
+     * it is tracked on stonyx-cron#35 alongside the execution timeout.
+     *
+     * NOT FIXED HERE: the phase split fixes the LOCK wedge, not the TIMER. A
+     * callback that never settles still stops `onTimer`'s sequential loop
+     * forever — `running` stays true, every later tick early-returns and re-arms,
+     * and the hung job's batch siblings stay claimed and off-heap having never
+     * been invoked. CRUD still resolves and `status()` still reports
+     * `started: true`, so that failure is now silent where it used to be loud.
+     * Bounding the callback and releasing batch siblings is stonyx-cron#35. Do
+     * not read this method's doc as "the hang is fixed".
      */
     async run(id, mode = 'force') {
         const job = this.jobs.get(id);
@@ -144,6 +397,10 @@ export default class CronService {
         if (mode === 'due' && !isDue(job, Date.now())) {
             return { status: 'skipped', reason: 'not due' };
         }
+        // Deliberately NOT wrapped in locked(): executeJob takes the lock itself,
+        // for its claim and settle phases only. Wrapping here would re-create the
+        // wedge through a second door, because the consumer callback would once
+        // again be awaited while a lock is held.
         return this.executeJob(job);
     }
     /**
@@ -172,16 +429,78 @@ export default class CronService {
         }
         this.running = true;
         try {
-            await locked(async () => {
+            // -- Phase 1: claim (locked), batched --
+            // Collecting due jobs pops them off the heap, and marking them running
+            // makes them un-claimable by anyone else. Both must happen under the
+            // same lock turn, or a concurrent run() could claim a job this batch has
+            // already detached.
+            //
+            // This is the SECOND claim implementation — `#claimJob` is the other, and
+            // the two reach the same state by different routes. `#claimJob` guards
+            // with an explicit `job.state.runningAtMs` check; this path has no such
+            // check and relies entirely on `isDue`'s `!job.state.runningAtMs` clause
+            // (`job.ts`) to keep `findDueJobs` from re-claiming a job that `run()`
+            // already holds. THAT CLAUSE IS LOAD-BEARING HERE, not an optimisation:
+            // drop it and the timer path silently double-invokes a job that `run()`
+            // is mid-flight on, while `run()` keeps refusing correctly and looks
+            // healthy. The one-in-flight-invocation-per-job invariant this class
+            // advertises holds by two independent guards in two files; a change to
+            // either has to be checked against the other.
+            const dueJobs = await locked(() => {
                 const nowMs = Date.now();
-                const dueJobs = this.findDueJobs(nowMs);
-                for (const job of dueJobs) {
+                const due = this.findDueJobs(nowMs);
+                for (const job of due) {
                     markRunning(job);
+                    inFlight.add(job);
                 }
-                for (const job of dueJobs) {
-                    await this.executeJob(job);
-                }
+                return due;
             });
+            // Phases 2 and 3 run OUTSIDE the claim lock. The consumer callback is
+            // awaited here holding no lock at all, so a callback that never settles
+            // cannot poison the lock chain and wedge add/update/remove.
+            for (const job of dueJobs) {
+                try {
+                    await this.#executeClaimed(job);
+                }
+                catch (err) {
+                    // One job's unexpected throw must not abort the batch. Every job in
+                    // `dueJobs` is already claimed — marked running and detached from
+                    // the heap — and only its own settle releases it, so aborting here
+                    // would strand every sibling permanently un-due.
+                    //
+                    // Reported on an UNGATED channel. `this.log()` returns early when
+                    // `config.cron.log` is false, which is a supported production
+                    // setting, and a failure here permanently unschedules a job while
+                    // `status()` keeps reporting the service healthy. Silent-and-healthy
+                    // is exactly the failure class this split exists to remove.
+                    //
+                    // This is the outermost handler on the timer path, so it is the one
+                    // that must not be able to throw: `log` is a shared singleton whose
+                    // transports can reach the filesystem, so its own failure is
+                    // swallowed rather than allowed to take the batch down.
+                    //
+                    // BOTH halves of that failure have to be caught, and they are caught
+                    // by different constructs. `log.error` is a chronicle convenience
+                    // method that returns `logAction(...)` -> `async log(...)`, so its
+                    // console write, colour lookup, `mkdirSync` and `appendFile` all
+                    // surface as REJECTIONS, never as synchronous throws. A bare call
+                    // here escapes this `catch` entirely and terminates the process under
+                    // Node's default `--unhandled-rejections=throw` — the handler written
+                    // so it "must not be able to throw" would be the one taking the
+                    // daemon down. The `try` covers the synchronous half (evaluating the
+                    // template literal); `Promise.resolve(...).catch()` covers the async
+                    // half. Deliberately not awaited: the batch must not block on a log
+                    // transport, and `void` marks the floated promise as intentional.
+                    try {
+                        void Promise.resolve(log.error(`Cron — Job "${forLog(job.name, MAX_LOGGED_NAME_LENGTH)}" (${job.id}) execution failed unexpectedly: ${forLog(describeError(err), MAX_LOGGED_ERROR_LENGTH)}`)).catch(() => {
+                            // Nothing left to report to.
+                        });
+                    }
+                    catch {
+                        // Nothing left to report to.
+                    }
+                }
+            }
         }
         finally {
             this.running = false;
@@ -202,50 +521,198 @@ export default class CronService {
         }
         return due;
     }
+    /**
+     * Execute a job in three phases:
+     *
+     *   1. claim  (locked)   — take ownership of the job, detach it from the heap
+     *   2. invoke (UNLOCKED) — await the consumer callback
+     *   3. settle (locked)   — apply the result, log it, re-insert into the heap
+     *
+     * The critical section deliberately excludes phase 2. `onJobDue` is
+     * arbitrary, unbounded consumer code; awaiting it under the module-global
+     * lock is what wedged every subsequent `locked()` call (add/update/remove)
+     * when a callback never settled.
+     *
+     * `onTimer` performs the batch claim (`findDueJobs` + `markRunning`) for all
+     * due jobs under a single lock and then enters at phase 2 via
+     * `#executeClaimed`. That entry point is `#private` rather than a parameter
+     * on this method: as a published `alreadyClaimed` flag it would be a
+     * supported way to skip phase 1 entirely, defeating the claim guard and
+     * allowing concurrent `onJobDue` invocations for the same job.
+     */
     async executeJob(job) {
+        // -- Phase 1: claim (locked) --
+        const refusal = await locked(() => this.#claimJob(job));
+        if (refusal)
+            return { status: 'skipped', reason: refusal };
+        return this.#executeClaimed(job);
+    }
+    /**
+     * Phases 2 and 3 for a job that has already been claimed — either by
+     * `executeJob` above or by `onTimer`'s batch claim.
+     *
+     * Private: reaching this without a claim would run the consumer callback for
+     * a job nobody owns, and would leave nothing to release the claim.
+     */
+    async #executeClaimed(job) {
+        // Membership re-check. The claim and the invoke are no longer in the same
+        // critical section, and sibling callbacks run unlocked, so a `remove()` can
+        // now land in between AND RESOLVE — it used to deadlock. A resolved
+        // `remove()` must keep meaning "this callback will not fire"; the identity
+        // guard in `#settleJob` only cleans up afterwards, by which point the side
+        // effect has already happened. Identity, not id, so a removed-then-replaced
+        // key is caught too. Deliberately synchronous with the `onJobDue` call
+        // below — nothing can interleave between this check and the invocation.
+        //
+        // This is the one early return after a claim, so it is the one that has to
+        // release the claim by hand. Skipping settle is right — re-inserting or
+        // run-logging a removed job is the resurrection `#settleJob` refuses, and
+        // the heap entry is already gone. But the claim must still come off,
+        // because the detached object is NOT unreachable: it is the object `add()`
+        // returned and `get()`/`list()` hand out, and `start(initialJobs)`
+        // re-registers those objects verbatim, `state` included. A leftover
+        // `runningAtMs` rehydrates a permanently dead job — `isDue` false forever,
+        // `run()` refused forever, `status()` reporting it healthy.
+        //
+        // Assigned directly rather than via `applyResult`: this releases the claim
+        // and nothing else. No run-log row, no heap entry, no `lastStatus`, no
+        // recomputed `nextRunAtMs` — the job did not run.
+        if (this.jobs.get(job.id) !== job) {
+            job.state.runningAtMs = undefined;
+            inFlight.delete(job);
+            return { status: 'skipped', reason: 'removed' };
+        }
         const startMs = Date.now();
         let status = 'ok';
         let error;
         let summary;
+        let settled;
+        // The claim marked the job running and detached it from the heap. Phase 3
+        // is the ONLY thing that undoes either, so it must survive every non-local
+        // exit from phase 2 — including a throw from the catch handler itself
+        // (`this.log` is public and overridable and reaches a transport). A claim
+        // with no matching settle is not a degraded state, it is a permanently
+        // dead job.
         try {
-            if (this.onJobDue) {
-                const result = await this.onJobDue(job);
-                if (result) {
-                    status = result.status || 'ok';
-                    error = result.error;
-                    summary = result.summary;
+            // -- Phase 2: invoke (NOT locked) --
+            try {
+                if (this.onJobDue) {
+                    const result = await this.onJobDue(job);
+                    if (result) {
+                        status = result.status || 'ok';
+                        error = result.error;
+                        summary = result.summary;
+                    }
                 }
             }
+            catch (err) {
+                status = 'error';
+                error = describeError(err);
+                this.log(`Job "${forLog(job.name, MAX_LOGGED_NAME_LENGTH)}" (${job.id}) failed: ${forLog(error, MAX_LOGGED_ERROR_LENGTH)}`);
+            }
         }
-        catch (err) {
-            status = 'error';
-            error = err instanceof Error ? err.message : String(err);
-            this.log(`Job "${job.name}" (${job.id}) failed: ${error}`);
+        finally {
+            // -- Phase 3: settle (locked) --
+            settled = await locked(() => this.#settleJob(job, status, error, summary, startMs, Date.now() - startMs));
         }
-        const durationMs = Date.now() - startMs;
-        const validStatus = (status === 'ok' || status === 'error' || status === 'skipped') ? status : 'error';
-        applyResult(job, validStatus, error, durationMs);
-        // Log the run
-        this.runLog.record({
-            jobId: job.id,
-            status,
-            error,
-            summary,
-            runAtMs: startMs,
-            durationMs,
-            nextRunAtMs: job.state.nextRunAtMs,
-        });
-        // Handle one-shot auto-delete
-        if (job.deleteAfterRun && status === 'ok' && !job.enabled) {
-            this.jobs.delete(job.id);
-            this.runLog.removeJob(job.id);
-            return { status, summary, deleted: true };
+        return settled;
+    }
+    /**
+     * Phase 1 — claim. Must be called while holding the lock (`locked()`, whose
+     * chain is module-global and therefore shared across CronService instances).
+     *
+     * Returns `null` on a successful claim, or the reason the claim was refused.
+     * `'already running'` is what makes a second `run()` report a skip instead of
+     * launching a concurrent invocation. `'removed'` covers the job being deleted
+     * between `run()`'s unlocked lookup and this lock turn — claiming then would
+     * `markRunning` an orphan and, worse, `removeFromHeap` an id that may now
+     * belong to a replacement.
+     *
+     * Detaching from the heap here — rather than relying on phase 3 to push a
+     * fresh entry — is what stops manual runs permanently duplicating entries.
+     *
+     * `#private`: published, this would be a supported call performing
+     * `markRunning` + `removeFromHeap` with no guaranteed settle and no lease on
+     * `runningAtMs`, so a single such call would strand the job forever. The
+     * lock-held precondition cannot be expressed in the type system, so the
+     * method must not be reachable from outside the class body.
+     */
+    #claimJob(job) {
+        if (this.jobs.get(job.id) !== job)
+            return 'removed';
+        if (job.state.runningAtMs)
+            return 'already running';
+        markRunning(job);
+        inFlight.add(job);
+        this.removeFromHeap(job.id);
+        return null;
+    }
+    /**
+     * Phase 3 — settle. Must be called while holding the lock.
+     *
+     * `#private` for the same reason as `#claimJob`: unlocked it would run
+     * `applyResult`, a `runLog.record`, a full `removeFromHeap` rebuild, a
+     * `heap.push` and an `armTimer` with no mutual exclusion — exactly the
+     * corruption `locked()` exists to prevent.
+     */
+    #settleJob(job, status, error, summary, startMs, durationMs) {
+        try {
+            const validStatus = (status === 'ok' || status === 'error' || status === 'skipped') ? status : 'error';
+            applyResult(job, validStatus, error, durationMs);
+            // The callback ran unlocked, so this job may have been removed — or
+            // removed and re-registered under the same id, the shape
+            // `start(initialJobs)` uses — while it was in flight. Identity, not id.
+            //
+            // Deliberately touch NOTHING here. The claim already detached this job's
+            // heap entry and nothing re-added it, so there is nothing to clean up;
+            // any entry now filed under this id belongs to the replacement, and
+            // removing it by id would silently unschedule a live job. Do not
+            // resurrect a removed job's heap entry or run log either.
+            if (this.jobs.get(job.id) !== job) {
+                return { status, error, summary, durationMs };
+            }
+            // Log the run
+            this.runLog.record({
+                jobId: job.id,
+                status,
+                error,
+                summary,
+                runAtMs: startMs,
+                durationMs,
+                nextRunAtMs: job.state.nextRunAtMs,
+            });
+            // Handle one-shot auto-delete. The callback ran unlocked and may have
+            // pushed a heap entry for this job via add()/update(), so drop it — the
+            // job is about to stop existing.
+            if (job.deleteAfterRun && status === 'ok' && !job.enabled) {
+                this.jobs.delete(job.id);
+                this.removeFromHeap(job.id);
+                this.runLog.removeJob(job.id);
+                return { status, summary, deleted: true };
+            }
+            // Re-insert into the heap if still active. Same reason as above: drop any
+            // entry the unlocked callback added for this job first, to preserve
+            // one-entry-per-key.
+            this.removeFromHeap(job.id);
+            if (job.enabled && job.state.nextRunAtMs) {
+                this.heap.push({ key: job.id, nextTrigger: job.state.nextRunAtMs });
+            }
+            return { status, error, summary, durationMs };
         }
-        // Re-insert into heap if still active
-        if (job.enabled && job.state.nextRunAtMs) {
-            this.heap.push({ key: job.id, nextTrigger: job.state.nextRunAtMs });
+        finally {
+            // The invocation is over, so this job is no longer in flight in this
+            // process — whatever `applyResult` did or did not manage to write. In the
+            // `finally` so it covers a throw out of `applyResult` or `runLog.record`
+            // too: past this point no settle is coming, which is precisely the state
+            // `start()`'s release is for.
+            inFlight.delete(job);
+            // One re-arm covering every exit, rather than one per branch. The claim
+            // detached this job from the heap, so a timer that fired during the
+            // unlocked invoke would have found nothing to arm — and `run()` has no
+            // `finally { armTimer() }` of its own the way `onTimer` does. Without
+            // this, a manual run() can leave the scheduler with no pending wake.
+            this.armTimer();
         }
-        return { status, error, summary, durationMs };
     }
     // -- Helpers ---------------------------------------------------------
     removeFromHeap(id) {

package/package.json

@@ -3,7 +3,7 @@
   "keywords": [
     "stonyx-module"
   ],
-  "version": "0.2.1-alpha.6",
+  "version": "0.2.1-alpha.61",
   "description": "Cron/job scheduler for Stonyx framework",
   "main": "dist/main.js",
   "types": "dist/main.d.ts",
@@ -69,18 +69,21 @@
   },
   "homepage": "https://github.com/abofs/stonyx-cron#readme",
   "devDependencies": {
-    "@stonyx/utils": "0.2.3-beta.7",
+    "@stonyx/utils": "0.2.3-beta.27",
     "@types/node": "^25.5.2",
+    "@types/qunit": "^2.19.13",
+    "@types/sinon": "^21.0.1",
     "qunit": "^2.24.1",
     "sinon": "^21.0.0",
+    "tsx": "^4.21.0",
     "typescript": "^5.8.3"
   },
   "dependencies": {
-    "stonyx": "0.2.3-beta.12"
+    "stonyx": "0.2.3-beta.93"
   },
   "scripts": {
     "build": "tsc",
     "build:test": "tsc -p tsconfig.test.json",
-    "test": "pnpm build && pnpm build:test && stonyx test 'dist-test/test/**/*-test.js'"
+    "test": "pnpm build && NODE_ENV=test node --import tsx/esm --import ./test/setup.ts node_modules/qunit/bin/qunit.js 'test/**/*-test.ts'"
   }
 }