cockroachdb/cockroach · critical · RequestError

Multiple schedules found for ID.

Error message

Multiple schedules found for ID.

What it means

Same system.schedules point lookup: if more than one row comes back for a single id, schedulesApi throws RequestError(500, 'Multiple schedules found for ID.'). id is the primary key of system.schedules, so multiple rows violate a table invariant — the 500 (vs the 400 for not-found) marks it as a server-side integrity problem, not bad input.

Source

Thrown at pkg/ui/workspaces/cluster-ui/src/api/schedulesApi.ts:132

                 state, recurrence, jobsrunning, owner,
                 created, jsonb_pretty(command) as command
          FROM schedules
          WHERE ID = $1::int64
        `,
        arguments: [id.toString()],
      },
    ],
    execute: true,
  };
  return executeInternalSql<ScheduleColumns>(request).then(result => {
    const txnResults = result.execution.txn_results;
    if (txnResults.length === 0 || !txnResults[0].rows) {
      // No data.
      throw new RequestError(400, "No schedule found with this ID.");
    }

    if (txnResults[0].rows.length > 1) {
      throw new RequestError(500, "Multiple schedules found for ID.");
    }
    const row = txnResults[0].rows[0];
    return {
      id: Long.fromString(row.id),
      label: row.label,
      status: row.schedule_status,
      nextRun: row.next_run ? moment.utc(row.next_run) : null,
      state: row.state,
      recurrence: row.recurrence,
      jobsRunning: row.jobsrunning,
      owner: row.owner,
      created: moment.utc(row.created),
      command: row.command,
    };
  });
}

View on GitHub (pinned to 8812064a01)

Solutions

  1. Check for duplicates: SELECT id, count(*) FROM system.schedules GROUP BY id HAVING count(*) > 1
  2. If duplicates exist, treat as cluster corruption: capture details and engage support / file an issue rather than deleting rows blindly
  3. If using a patched console, diff schedulesApi.ts to confirm the WHERE ID = $1::int64 predicate and int64 cast are intact
Defensive patterns

Strategy: try-catch

Type guard

const isRequestError = (
  e: unknown,
  status?: number,
): e is RequestError =>
  e instanceof RequestError && (status === undefined || e.status === status);

Try / catch

try {
  const schedule = await getSchedule(id);
} catch (e) {
  if (isRequestError(e, 500)) {
    // Invariant violation on a PK table: report, do not retry blindly
    reportError(e);
    return <Alert type='error' title='Schedule data integrity problem' />;
  }
  throw e;
}

Prevention

When it happens

Trigger: SELECT ... WHERE ID = $1 returning >1 row, which requires duplicate primary-key values in system.schedules — realistically only from table corruption or a patched/custom query that lost the equality predicate.

Common situations: Essentially never in healthy clusters; appears after manual fiddling with system.schedules rows, disk-level corruption, or a modified schedulesApi query (e.g. accidental LIKE or missing WHERE).

Related errors


AI-assisted analysis of cockroachdb/cockroach@8812064a01 (2026-08-15). Data as JSON: /api/errors/76d29af4d7fb8693. Report an issue: GitHub.