anbaric 1.56.6 → 1.56.8

package/docs/api/environment.md

@@ -49,6 +49,7 @@ Used by the store implementations the factories return:
 | `ANBARIC_SQL_DATABASE_URL` | PostgreSQL | connection string |
 | `ANBARIC_SQL_SCHEMA` | PostgreSQL | schema name (default `anbaric_app_data`) |
 | `ANBARIC_FILE_STORAGE_PATH` | local file storage | directory to keep files in (default `<temp dir>/anbaric/files`) |
+| `ANBARIC_SCHEDULER_TICK_MS` | the job run scheduler | how often due runs are checked for, in milliseconds (default `10000`) |
 
 ## Platform-injected variables
 

package/docs/api/state-machine.md

@@ -348,6 +348,13 @@ Storage comes from `JobRunSchedulePersistenceFactory` — in memory locally, the
 platform database when deployed, where claiming a due run is atomic so several
 instances can schedule the same machines safely.
 
+Claiming coalesces: when more than one of a machine's runs has come due — the
+scheduler was down, a deploy took a while — only the most recent is claimed
+and started, and the earlier ones are recorded as **superseded** by it
+(`superseded_at` and `superseded_by` on the stored run). The consumer is sent
+one catch-up job, never one per missed tick. Runs of different machines, or
+of the same machine in different apps, are never coalesced with each other.
+
 ---
 
 ## `Actor`

package/docs/features/scheduled-runs.md

@@ -53,10 +53,14 @@ runs as they come due. Two things follow from that, both deliberate:
 
 - **A restart doesn't lose the timetable.** The plan is already stored, so the
   scheduler picks up where it left off.
-- **Downtime doesn't silently skip runs.** A scheduler that was down for two
-  days starts the runs it missed as soon as it comes back, rather than
-  pretending they never existed. If you don't want that catch-up for a
-  particular machine, make its action check `scheduledFor` and return early.
+- **Downtime doesn't silently skip runs — and doesn't replay them either.** A
+  scheduler that was down for two days starts **one** catch-up run as soon as
+  it comes back: the most recent run it missed. The earlier missed runs are
+  recorded as superseded by it, so the timetable shows what was skipped and
+  why, but an hourly sync that missed a day never becomes twenty-four syncs
+  fired in the same second. The job's `scheduledFor` tells you which run it
+  is; if a machine must not catch up at all, make its action check that and
+  return early.
 
 Every scheduled job carries the run it belongs to:
 
@@ -69,6 +73,9 @@ processRun.run = async (job) => {
 
 ## Spreading the load
 
+The scheduler checks for due runs every ten seconds (`ANBARIC_SCHEDULER_TICK_MS`
+changes that), so a run starts within ten seconds of its planned time.
+
 Machines scheduled at the same time would otherwise all start on the same
 second. Each machine gets a small random offset — up to two minutes by default —
 applied **when the run is planned**, so the stored time is the time it really

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "anbaric",
-  "version": "1.56.6",
+  "version": "1.56.8",
   "description": "Everything needed to write an Anbaric app: state machines, jobs, document and secret stores, local in-memory implementations and the Anbaric Cloud clients",
   "license": "MIT",
   "type": "module",
@@ -24,9 +24,9 @@
     "prepublishOnly": "npm run build"
   },
   "dependencies": {
-    "anbaric-impl-cloud": "^1.56.6",
-    "anbaric-data-store": "^1.56.6",
-    "anbaric-state-machine": "^1.56.6",
-    "anbaric-tsapi": "^1.56.6"
+    "anbaric-impl-cloud": "^1.56.8",
+    "anbaric-data-store": "^1.56.8",
+    "anbaric-state-machine": "^1.56.8",
+    "anbaric-tsapi": "^1.56.8"
   }
 }