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
- Force `fromStatus = null` when kind is `Added`.
- Split the builder: a dedicated `buildAddedEvent(...)` that does not accept a fromStatus.
- 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
- Use dedicated builders per event kind rather than one generic factory.
- Treat `Added` as semantically distinct from a transition — no fromStatus.
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
- Started must enter an active status
- Paused must transition from active to paused
- Resumed must transition from paused to active
- Completed must end in completed
- Failed must end in error
AI-assisted analysis of agalwood/Motrix@1a708ee577 (2026-08-12).
Data as JSON: /api/errors/9fd7f8aae5b36acf.
Report an issue: GitHub.