@stonyx/cron 0.2.1-beta.150 → 0.2.1-beta.152
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +21 -2
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -43,9 +43,27 @@ When a job is executed, its next trigger time is updated, and it is re-inserted
|
|
|
43
43
|
>
|
|
44
44
|
> 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.
|
|
45
45
|
>
|
|
46
|
+
> **Re-registering a key does not replace its job.** Calling `register` with a key that is already registered leaves the old job firing on its old schedule, and `unregister(key)` can no longer remove it. Call `unregister(key)` first. See [docs/architecture.md](docs/architecture.md) (known limitation).
|
|
47
|
+
>
|
|
46
48
|
> 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`.
|
|
47
49
|
|
|
48
|
-
|
|
50
|
+
## Exports
|
|
51
|
+
|
|
52
|
+
| Import path | What it exports |
|
|
53
|
+
| :--- | :--- |
|
|
54
|
+
| `@stonyx/cron` | `Cron` (default), the interval registry above |
|
|
55
|
+
| `@stonyx/cron/service` | `CronService` (default), see [CronService](#cronservice) |
|
|
56
|
+
| `@stonyx/cron/schedule` | `computeNextRunAtMs`, `validateSchedule`, and the `Schedule` types |
|
|
57
|
+
| `@stonyx/cron/cron-parser` | `parseCronExpression`, `parseField`, `nextOccurrence`, `validateCronExpression` |
|
|
58
|
+
| `@stonyx/cron/job` | `createJob`, `updateJob`, `applyResult`, `isDue`, `markRunning`, `errorBackoffMs`, and the `Job` types |
|
|
59
|
+
| `@stonyx/cron/normalize` | `normalizeJobInput`, `normalizeSchedule`, `normalizePayload`, `recoverFlatParams` |
|
|
60
|
+
| `@stonyx/cron/run-log` | `RunLog` (default) |
|
|
61
|
+
| `@stonyx/cron/locked` | `locked`, `resetLock` |
|
|
62
|
+
| `@stonyx/cron/min-heap` | `MinHeap` (default) |
|
|
63
|
+
|
|
64
|
+
## Samples
|
|
65
|
+
|
|
66
|
+
[`test/sample/`](https://github.com/abofs/stonyx-cron/tree/dev/test/sample) is the canonical usage reference for job definitions: legacy `Cron` intervals and every `CronService` schedule kind. It is not included in the npm package.
|
|
49
67
|
|
|
50
68
|
## CronService
|
|
51
69
|
|
|
@@ -90,7 +108,8 @@ timer loop for every other job** — silently, with `status()` still reporting
|
|
|
90
108
|
callback is your responsibility, exactly as it is for `Cron`. Only a real
|
|
91
109
|
process restart recovers it: `start()` releases a claim whose owner is provably
|
|
92
110
|
gone, but an object still held in this process is deliberately left alone.
|
|
93
|
-
|
|
111
|
+
No execution timeout is implemented or currently tracked; see
|
|
112
|
+
[docs/service-design.md](docs/service-design.md#what-the-phase-split-does-not-fix-a-hung-callback-stops-the-timer).
|
|
94
113
|
|
|
95
114
|
### Breaking changes in this line
|
|
96
115
|
|