perf: optimize step boundary cancellation check

[coji]

Context

step.run() calls storage.getRun(run.id) at every step boundary to check if the run was cancelled. For a job with N steps, this adds N extra DB queries on the hot path.

With #37 (AbortSignal support), we now have an in-memory run:cancel event listener that sets controller.signal.aborted = true synchronously. This could be used to skip the DB query in most cases.

Idea

Check controller.signal.aborted first. Only fall back to the DB query when the signal hasn't been aborted (to handle edge cases like worker restart replay where the event never fired).

// Fast path: check in-memory signal first
if (controller.signal.aborted) {
  throw new CancelledError(run.id)
}

// Slow path: DB check for cases where event wasn't received
// (e.g., run cancelled while worker was down, then resumed)
const currentRun = await storage.getRun(run.id)
if (currentRun?.status === 'cancelled') {
  controller.abort()
  throw new CancelledError(run.id)
}

Additional: Check signal during step replay

Currently, completed steps returned from cache (getCompletedStep) don't check controller.signal.aborted. During replay of many completed steps, cancellation is only detected at the next uncompleted step's DB check. Adding a signal check before getCompletedStep would make cancellation more responsive during replay, at near-zero cost:

// Add before the getCompletedStep call
if (controller.signal.aborted) {
  throw new CancelledError(run.id)
}

Considerations

• The DB check is still needed for resume/replay scenarios
• Could also consider only doing the DB check every Nth step or after a time threshold
• Measure actual impact before optimizing — may not matter for typical workloads

Related

• feat: support AbortSignal in step.run for cooperative cancellation #37 — AbortSignal support in step.run