@lunora/scheduler 1.0.0-alpha.80 → 1.0.0-alpha.81

package/dist/index.d.mts

@@ -1274,13 +1274,14 @@ declare class SchedulerDO {
    * INSTANCE id for a `workflow` target. A mutation's dedup read runs inside
    * the shard's single-writer gate, so a mutation is exactly-once even under a
    * genuinely concurrent re-fire; a workflow re-attaches to the running
-   * instance rather than starting a second one. An ACTION is weaker:
-   * `@lunora/do` deliberately does NOT take the gate for a non-mutation —
+   * instance rather than starting a second one. An ACTION takes no gate —
    * gating one would let any caller freeze a whole shard for the length of an
    * action's outbound I/O — and its dedup row is written only after the
-   * handler returns, so two dispatches genuinely overlapping in time can both
-   * miss the cache. The lease exists to keep them from overlapping; an action
-   * that can outlive it must still be idempotent.
+   * handler returns, so the cache alone could not tell "already ran" from
+   * "still running". The shard closes that itself (#803): it claims the dedup
+   * key before entering the handler and answers a second delivery of a live
+   * key `409 DISPATCH_IN_PROGRESS`, which is a non-2xx, so the record is
+   * re-armed rather than cleared.
    *
    * Two bounded walks (all `t:` values, then all `id:` headers) rather than a
    * per-header `get`, so the cost is one pass over each prefix.

package/dist/index.d.ts

@@ -1274,13 +1274,14 @@ declare class SchedulerDO {
    * INSTANCE id for a `workflow` target. A mutation's dedup read runs inside
    * the shard's single-writer gate, so a mutation is exactly-once even under a
    * genuinely concurrent re-fire; a workflow re-attaches to the running
-   * instance rather than starting a second one. An ACTION is weaker:
-   * `@lunora/do` deliberately does NOT take the gate for a non-mutation —
+   * instance rather than starting a second one. An ACTION takes no gate —
    * gating one would let any caller freeze a whole shard for the length of an
    * action's outbound I/O — and its dedup row is written only after the
-   * handler returns, so two dispatches genuinely overlapping in time can both
-   * miss the cache. The lease exists to keep them from overlapping; an action
-   * that can outlive it must still be idempotent.
+   * handler returns, so the cache alone could not tell "already ran" from
+   * "still running". The shard closes that itself (#803): it claims the dedup
+   * key before entering the handler and answers a second delivery of a live
+   * key `409 DISPATCH_IN_PROGRESS`, which is a non-2xx, so the record is
+   * re-armed rather than cleared.
    *
    * Two bounded walks (all `t:` values, then all `id:` headers) rather than a
    * per-header `get`, so the cost is one pass over each prefix.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lunora/scheduler",
-  "version": "1.0.0-alpha.80",
+  "version": "1.0.0-alpha.81",
   "description": "Scheduling for Lunora: runAfter / runAt and Cron Triggers via SchedulerDO",
   "keywords": [
     "cloudflare",
@@ -46,7 +46,7 @@
     "access": "public"
   },
   "dependencies": {
-    "@lunora/errors": "1.0.0-alpha.40",
+    "@lunora/errors": "1.0.0-alpha.41",
     "@lunora/platform": "1.0.0-alpha.33",
     "cron-parser": "5.10.0"
   },