@stonyx/cron 0.2.1-alpha.44 → 0.2.1-alpha.45
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 +15 -3
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -35,22 +35,34 @@ When a job is executed, its next trigger time is updated, and it is re-inserted
|
|
|
35
35
|
| `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. |
|
|
36
36
|
| `unregister` | `key: string` | Remove a previously registered job. |
|
|
37
37
|
|
|
38
|
-
>
|
|
38
|
+
> **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.
|
|
39
|
+
>
|
|
40
|
+
> 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.
|
|
41
|
+
>
|
|
42
|
+
> 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.
|
|
43
|
+
>
|
|
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
|
+
>
|
|
46
|
+
> 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`.
|
|
39
47
|
|
|
40
48
|
> `MinHeap` is also exported as a public subpath (`@stonyx/cron/min-heap`) and can be imported directly for advanced usage.
|
|
41
49
|
|
|
42
50
|
## Configuration
|
|
43
51
|
|
|
44
|
-
Optionally, logging and debugging can be
|
|
52
|
+
Optionally, informational logging and debugging can be controlled through `config.cron`:
|
|
45
53
|
|
|
46
54
|
```js
|
|
47
55
|
config.cron = {
|
|
48
|
-
log: true //
|
|
56
|
+
log: true // informational cron job logs; defaults to true
|
|
49
57
|
};
|
|
50
58
|
|
|
51
59
|
config.debug = true; // optional: debug logs for job registration and execution
|
|
52
60
|
```
|
|
53
61
|
|
|
62
|
+
`config.cron.log` gates **informational** messages only. Error reports and the
|
|
63
|
+
stuck-job warning described above are never gated by it, so setting it to `false`
|
|
64
|
+
cannot make a dropped execution silent.
|
|
65
|
+
|
|
54
66
|
## License
|
|
55
67
|
|
|
56
68
|
Apache — do what you want, just keep attribution.
|