jackwener/OpenCLI · error · CommandExecutionError

Slock ${commandName} returned task id ${taskId}, expected ${

Error message

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

What it means

assertTaskIdentity also enforces that the id on the returned task row strictly equals the id the caller asked to operate on. A mismatch means the server returned a different task than requested — e.g. the lookup by number/channel resolved to another row. Throwing here prevents reading, updating, or deleting the wrong task.

Source

Thrown at clis/slock/task-identity.js:9

import { CommandExecutionError } from '@jackwener/opencli/errors';

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

View on GitHub (pinned to 49907e53dc)

Solutions

Print the returned taskId from the error and check which task it actually points to
Look the task up by its exact id rather than by number to avoid ambiguous resolution
Verify the --channel/--server flags resolve to the channel you expect before fetching by number
If taskNumbers collided, renumber or deduplicate the tasks server-side

Example fix

// before (resolving by ambiguous number)
const row = await fetchTaskByNumber(channel, 12);
assertTaskIdentity(row, expectedId, 'task-get');
// after
const row = await fetchTaskById(expectedId);
assertTaskIdentity(row, expectedId, 'task-get');

Defensive patterns

Strategy: validation

Validate before calling

if (row && row.id && row.id !== expectedId) {
  console.warn(`Server returned ${row.id}, expected ${expectedId}; aborting.`);
}

Type guard

const isSameTask = (t, expectedId) => t != null && t.id === expectedId;

Try / catch

try {
  assertTaskIdentity(row, expectedId, commandName);
} catch (e) {
  if (/returned task id/.test(e.message)) {
    // refetch by exact id instead of ambiguous number/channel lookup
  }
  throw e;
}

Prevention

Prefer lookups by exact id over by number/channel to avoid ambiguous resolution
Verify --channel/--server flags resolve to the intended channel before number-based fetches
Deduplicate/renumber taskNumbers if collisions exist server-side

When it happens

Trigger: A command resolves a task by number or channel and then asserts identity with the expected id, but the fetched row's `id` differs from expectedId: duplicate taskNumbers in a channel, channel resolution picking a different channel than intended, or stale cached expectedId.

Common situations: Two tasks share the same taskNumber after a channel rename/re-import; the user passed a number from one channel while the CLI resolved another; server-side reindexing changed ids; tests asserting against hardcoded ids after data changed.

Related errors

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