jackwener/OpenCLI · error · CommandExecutionError

Slock task-status returned status ${taskStatus}, expected ${

Error message

Slock task-status returned status ${taskStatus}, expected ${expectedStatus}.

What it means

assertTaskMutationIdentity final check: the status returned for the task must equal the status the command expected (the status the mutation was supposed to produce). This throw fires when the task was found with the right id but its status differs, meaning the mutation did not take effect as expected and the CLI refuses to fabricate a success row.

Source

Thrown at clis/slock/task-status.js:90

      };
    });
  },
});

function assertTaskMutationIdentity(t, expectedId, expectedStatus) {
  const taskId = t?.id;
  if (!taskId) {
    throw new CommandExecutionError(`Slock task-status succeeded without returning task id ${expectedId}; refusing to report a status row.`);
  }
  if (taskId !== expectedId) {
    throw new CommandExecutionError(`Slock task-status returned task id ${taskId}, expected ${expectedId}.`);
  }
  const taskStatus = t.taskStatus ?? t.status;
  if (!taskStatus) {
    throw new CommandExecutionError(`Slock task-status returned task ${expectedId} without taskStatus.`);
  }
  if (taskStatus !== expectedStatus) {
    throw new CommandExecutionError(`Slock task-status returned status ${taskStatus}, expected ${expectedStatus}.`);
  }
  return { taskId, taskStatus };
}

View on GitHub (pinned to 49907e53dc)

Solutions

Re-run the command — transient replication lag often resolves on retry.
Print the actual status from the error message and update your expected status/automation accordingly.
Check for concurrent writers (other agents, web UI sessions) mutating the same task.
Verify the mutation endpoint actually succeeded (check HTTP status in the snippet) before assuming a status transition.

Example fix

// before
await cli.run(['task-status', id, '--expected-status', 'done']);
// after: poll until the expected status appears
for (let i = 0; i < 5; i++) {
  try { await cli.run(['task-status', id, '--expected-status', 'done']); break; }
  catch (e) { if (i === 4) throw e; await sleep(500); }
}

Defensive patterns

Strategy: retry

Try / catch

for (let attempt = 0; attempt < 3; attempt++) {
  try { await cli.run(['task-status', id, '--expected-status', want]); break; }
  catch (e) {
    if (String(e.message).includes('returned status') && attempt < 2) await sleep(500);
    else throw e;
  }
}

Prevention

Retry on status mismatches to absorb replication lag
Avoid concurrent writers to the same task
Derive expected status from the workflow, not hardcoded values

When it happens

Trigger: Requesting a status transition (e.g. expecting `done`) but the API returns the task still in `in_progress` — concurrent updates, optimistic-lock rejection rendered as success, eventual consistency on replicas, or the wrong expected status passed to the command.

Common situations: Another agent/user moved the task between your call and the read; hitting a read-replica that lags the write; passing a hardcoded expected status that no longer matches workflow state; terminal-status tasks rejecting further transitions.

Related errors

AI-assisted analysis of jackwener/OpenCLI@49907e53dc (2026-08-29). Data as JSON: /api/errors/edd0897c2eebb324. Report an issue: GitHub.