jackwener/OpenCLI · error · CommandExecutionError

Slock task-status returned task id ${taskId}, expected ${exp

Error message

Slock task-status returned task id ${taskId}, expected ${expectedId}.

What it means

assertTaskMutationIdentity compares the `id` of the task object returned by the task-status API against the task id the user asked about. This throw fires when the API succeeded but returned a DIFFERENT task id than requested, so the command refuses to show a misleading status row.

Source

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

    return rows.map((t) => {
      const task = assertTaskMutationIdentity(t, id, status);
      return {
        taskId: task.taskId,
        taskStatus: task.taskStatus,
        assigneeId: t.claimedById ?? t.assigneeId ?? null,
        taskNumber: t.taskNumber ?? null,
      };
    });
  },
});

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-check the task id you passed; fetch the canonical id from `task-list` on the same server.
Remove or correct the `--server` override so you query the backend the id belongs to.
Confirm no middleware rewrites request/response bodies between the browser page and the API.
Capture the returned id from the error message and inspect that task to identify the mixup.

Example fix

// before
await cli.run(['task-status', oldId]);
// after: resolve the id on the target server first
const rows = await cli.run(['task-list', '--server', 'prod']);
const id = rows.find(r => r.taskNumber === 42).taskId;
await cli.run(['task-status', id]);

Defensive patterns

Strategy: validation

Validate before calling

const known = await cli.run(['task-list', '--server', server]);
if (!known.some(r => r.taskId === id)) throw new Error(`unknown task id ${id} on ${server}`);

Try / catch

try {
  await cli.run(['task-status', id, '--server', server]);
} catch (e) {
  if (String(e.message).includes('expected')) {
    const m = e.message.match(/returned task id ([^,]+)/);
    console.error(`id mixup: got ${m?.[1]}, wanted ${id}`);
  } else throw e;
}

Prevention

Resolve ids from task-list on the same server before mutating
Avoid reusing ids across --server overrides
Watch for proxies that rewrite bodies

When it happens

Trigger: Running `slock task-status <id>` when the endpoint resolves a different task (wrong id passed, server override (`--server`) pointing at a different backend with colliding ids, or a cache/proxy serving a stale or rewritten record).

Common situations: Copy/paste of a task id from another server; using a short id where the API silently matched a different record; switching active servers with `--server` while reusing old ids; API routing bugs after version upgrades.

Related errors

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