Read against 0.10.1.
Problem
There is no onCancelled callback. The lifecycle set is onQueued / onCompleted / onFailed, and
withQueuedNotification decorates enqueue only — so a cancelled job simply stops existing and the
host is never told.
Two paths hit this:
- Explicit cancellation.
POST /translate/cancel {ids} → TaskRunner.cancel(taskIds), which under
the payload-jobs runner calls payload.jobs.cancel(...) and then hard-payload.deletes the job
rows. A pending job vanishes silently.
- The plugin's own supersede path.
enqueue already supersedes per (document, target locale),
cancelling and deleting the prior job. So the plugin cancels jobs on its own initiative and tells
nobody.
Task.cancelled does not help: it derives from error.cancelled on the job row, and the plugin
deletes the row it just cancelled.
Why this matters
A host tracking per-document translation state has to model "this run is no longer happening". With no
callback, it has to infer that — we release our own state first and treat the plugin call as
best-effort, which works but means the plugin and the host can disagree about what is in flight,
particularly on the supersede path where the host never asked for a cancellation at all.
Suggested shape
onCancelled(document, targetLocale, reason) where reason distinguishes an explicit cancel from a
supersede. Firing it before the job row is deleted would let a host read the row if it needs to.
Read against 0.10.1.
Problem
There is no
onCancelledcallback. The lifecycle set isonQueued/onCompleted/onFailed, andwithQueuedNotificationdecoratesenqueueonly — so a cancelled job simply stops existing and thehost is never told.
Two paths hit this:
POST /translate/cancel {ids}→TaskRunner.cancel(taskIds), which underthe payload-jobs runner calls
payload.jobs.cancel(...)and then hard-payload.deletes the jobrows. A pending job vanishes silently.
enqueuealready supersedes per (document, target locale),cancelling and deleting the prior job. So the plugin cancels jobs on its own initiative and tells
nobody.
Task.cancelleddoes not help: it derives fromerror.cancelledon the job row, and the plugindeletes the row it just cancelled.
Why this matters
A host tracking per-document translation state has to model "this run is no longer happening". With no
callback, it has to infer that — we release our own state first and treat the plugin call as
best-effort, which works but means the plugin and the host can disagree about what is in flight,
particularly on the supersede path where the host never asked for a cancellation at all.
Suggested shape
onCancelled(document, targetLocale, reason)wherereasondistinguishes an explicit cancel from asupersede. Firing it before the job row is deleted would let a host read the row if it needs to.