@stonyx/cron 0.2.1-alpha.51 → 0.2.1-alpha.52
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/dist/service.d.ts +17 -1
- package/dist/service.js +17 -1
- package/package.json +1 -1
package/dist/service.d.ts
CHANGED
|
@@ -84,6 +84,12 @@ export default class CronService {
|
|
|
84
84
|
* (`'removed'`). Before the phase split, a forced run against an in-flight
|
|
85
85
|
* job launched a second concurrent invocation.
|
|
86
86
|
*
|
|
87
|
+
* THROWS (rather than returning a skip) when `id` is not a registered job:
|
|
88
|
+
* `Error("Job not found: <id>")`. A job that disappears between this lookup
|
|
89
|
+
* and the claim is the `'removed'` skip above, not a throw — the two differ
|
|
90
|
+
* only by the timing of a race, and the second is a legitimate outcome
|
|
91
|
+
* whereas the first is a caller error.
|
|
92
|
+
*
|
|
87
93
|
* CONCURRENCY: the same job is bounded to one in-flight invocation on every
|
|
88
94
|
* path, and the timer path invokes due jobs one at a time. `run()` fan-out
|
|
89
95
|
* across DIFFERENT jobs is deliberately unbounded — N concurrent `run()`
|
|
@@ -91,7 +97,17 @@ export default class CronService {
|
|
|
91
97
|
* these serialized behind the module-global lock; that serialization was the
|
|
92
98
|
* bug rather than the feature (one hung callback wedged every other caller),
|
|
93
99
|
* so it is not restored here. The fan-out is caller-driven and the scheduler
|
|
94
|
-
* never produces it on its own.
|
|
100
|
+
* never produces it on its own. A per-invoke bound belongs above this layer;
|
|
101
|
+
* it is tracked on stonyx-cron#35 alongside the execution timeout.
|
|
102
|
+
*
|
|
103
|
+
* NOT FIXED HERE: the phase split fixes the LOCK wedge, not the TIMER. A
|
|
104
|
+
* callback that never settles still stops `onTimer`'s sequential loop
|
|
105
|
+
* forever — `running` stays true, every later tick early-returns and re-arms,
|
|
106
|
+
* and the hung job's batch siblings stay claimed and off-heap having never
|
|
107
|
+
* been invoked. CRUD still resolves and `status()` still reports
|
|
108
|
+
* `started: true`, so that failure is now silent where it used to be loud.
|
|
109
|
+
* Bounding the callback and releasing batch siblings is stonyx-cron#35. Do
|
|
110
|
+
* not read this method's doc as "the hang is fixed".
|
|
95
111
|
*/
|
|
96
112
|
run(id: string, mode?: 'due' | 'force'): Promise<ExecuteResult>;
|
|
97
113
|
/**
|
package/dist/service.js
CHANGED
|
@@ -222,6 +222,12 @@ export default class CronService {
|
|
|
222
222
|
* (`'removed'`). Before the phase split, a forced run against an in-flight
|
|
223
223
|
* job launched a second concurrent invocation.
|
|
224
224
|
*
|
|
225
|
+
* THROWS (rather than returning a skip) when `id` is not a registered job:
|
|
226
|
+
* `Error("Job not found: <id>")`. A job that disappears between this lookup
|
|
227
|
+
* and the claim is the `'removed'` skip above, not a throw — the two differ
|
|
228
|
+
* only by the timing of a race, and the second is a legitimate outcome
|
|
229
|
+
* whereas the first is a caller error.
|
|
230
|
+
*
|
|
225
231
|
* CONCURRENCY: the same job is bounded to one in-flight invocation on every
|
|
226
232
|
* path, and the timer path invokes due jobs one at a time. `run()` fan-out
|
|
227
233
|
* across DIFFERENT jobs is deliberately unbounded — N concurrent `run()`
|
|
@@ -229,7 +235,17 @@ export default class CronService {
|
|
|
229
235
|
* these serialized behind the module-global lock; that serialization was the
|
|
230
236
|
* bug rather than the feature (one hung callback wedged every other caller),
|
|
231
237
|
* so it is not restored here. The fan-out is caller-driven and the scheduler
|
|
232
|
-
* never produces it on its own.
|
|
238
|
+
* never produces it on its own. A per-invoke bound belongs above this layer;
|
|
239
|
+
* it is tracked on stonyx-cron#35 alongside the execution timeout.
|
|
240
|
+
*
|
|
241
|
+
* NOT FIXED HERE: the phase split fixes the LOCK wedge, not the TIMER. A
|
|
242
|
+
* callback that never settles still stops `onTimer`'s sequential loop
|
|
243
|
+
* forever — `running` stays true, every later tick early-returns and re-arms,
|
|
244
|
+
* and the hung job's batch siblings stay claimed and off-heap having never
|
|
245
|
+
* been invoked. CRUD still resolves and `status()` still reports
|
|
246
|
+
* `started: true`, so that failure is now silent where it used to be loud.
|
|
247
|
+
* Bounding the callback and releasing batch siblings is stonyx-cron#35. Do
|
|
248
|
+
* not read this method's doc as "the hang is fixed".
|
|
233
249
|
*/
|
|
234
250
|
async run(id, mode = 'force') {
|
|
235
251
|
const job = this.jobs.get(id);
|