fix: separate worker completion from durable session delivery
This commit is contained in:
@@ -41,18 +41,16 @@ export function unregisterJobAbort(jobId: string): void {
|
||||
* the liveness gate for the stale-job sweep: a "running" record with a
|
||||
* live registration belongs to a loop this process owns (hung or slow, it
|
||||
* is the one truth — never re-spawn beside it); without one the record is
|
||||
* an orphan of a process death and recovers immediately. The span is
|
||||
* loop-start to delivery-completion: the runner's unregistering finally
|
||||
* runs only after deliver() resolves, by which point finalizeJob has
|
||||
* flipped the record — so absence of registration is unambiguous. */
|
||||
* an orphan of a process death and recovers immediately. The registration
|
||||
* spans computation and cleanup only. Finished outcomes have independent,
|
||||
* persisted delivery obligations; no worker waits for their consumption. */
|
||||
export function isJobLive(jobId: string): boolean {
|
||||
return registry().has(jobId);
|
||||
}
|
||||
|
||||
/** Abort a running job's loop. Returns false when no controller is live —
|
||||
* the job's loop is not executing (crashed, or in the delivering-result
|
||||
* phase where the runner has already returned); the caller then owns the
|
||||
* whole abort on the record side. */
|
||||
* the job's loop is not executing. The endpoint separately refuses abort
|
||||
* for a finished worker, even while its session delivery remains pending. */
|
||||
export function fireJobAbort(jobId: string): boolean {
|
||||
const controller = registry().get(jobId);
|
||||
if (!controller) return false;
|
||||
|
||||
Reference in New Issue
Block a user