agalwood/Motrix · error · RangeError

Added must not have a fromStatus

Error message

Added must not have a fromStatus

What it means

The first switch arm of the state machine: for `TaskHistoryEventKind.Added` (task creation), `fromStatus` must be `null` because there is no previous status. Throws this `RangeError` if `fromStatus` is set. This prevents confusion between an Add event and a transition.

Source

Thrown at src/core/inspector-activity/validators.ts:204

    input.errorMessage,
    'errorMessage',
    MAX_ERROR_MESSAGE_LENGTH
  )
  assertBoundedText(
    input.errorDetailKey,
    'errorDetailKey',
    MAX_ERROR_DETAIL_KEY_LENGTH
  )
  assertBoundedDetailParams(
    input.errorDetailParams,
    'errorDetailParams',
    MAX_ERROR_DETAIL_PARAMS_JSON_LENGTH
  )

  switch (input.kind) {
    case TaskHistoryEventKind.Added:
      if (input.fromStatus !== null) {
        throw new RangeError('Added must not have a fromStatus')
      }
      break
    case TaskHistoryEventKind.Started:
      if (!ACTIVE_RESUME_STATUSES.has(input.toStatus)) {
        throw new RangeError('Started must enter an active status')
      }
      break
    case TaskHistoryEventKind.Paused:
      if (
        input.fromStatus === null ||
        !ACTIVE_RESUME_STATUSES.has(input.fromStatus) ||
        input.toStatus !== TaskStatus.Paused
      ) {
        throw new RangeError('Paused must transition from active to paused')
      }
      break
    case TaskHistoryEventKind.Resumed:
      if (

View on GitHub (pinned to 1a708ee577)

Solutions

  1. Force `fromStatus = null` when kind is `Added`.
  2. Split the builder: a dedicated `buildAddedEvent(...)` that does not accept a fromStatus.
  3. Validate at the producer with `assert(kind !== Added || fromStatus === null)`.

Example fix

// before
{ kind: TaskHistoryEventKind.Added, fromStatus: TaskStatus.Queued, toStatus: TaskStatus.Queued }
// after
{ kind: TaskHistoryEventKind.Added, fromStatus: null, toStatus: TaskStatus.Queued }
Defensive patterns

Strategy: validation

Validate before calling

if (input.kind === TaskHistoryEventKind.Added) input.fromStatus = null

Prevention

When it happens

Trigger: Constructing an Added event but populating `fromStatus` with `TaskStatus.Queued` (or anything else) — typically copy-pasted from a transition template or set by a generic builder that always fills both statuses.

Common situations: Generic event builders that default `fromStatus` to the current persisted status; replaying a task's first event with the previous row's leftover state; tests reusing a transition fixture for an Added case.

Related errors


AI-assisted analysis of agalwood/Motrix@1a708ee577 (2026-08-12). Data as JSON: /api/errors/9fd7f8aae5b36acf. Report an issue: GitHub.