[mergeConnections] Update skipped: Original connection "${or

Error message

[mergeConnections] Update skipped: Original connection "${originalDatabaseId}" not found

What it means

SystemSettings.mergeConnections received an 'update' action whose originalDatabaseId is not a key in the current connections map (the persisted vector-DB connection list), so that single update is skipped to avoid writing a bogus entry; the rest of the merge proceeds. The map is keyed by slugified connection ids.

Source

Thrown at server/models/systemSettings.js:1184

      database_id,
      originalDatabaseId,
      connectionString,
      engine,
      schema,
    } = update;

    switch (action) {
      case "remove": {
        connectionsMap.delete(database_id);
        break;
      }
      case "update": {
        if (!connectionString) continue;
        const newId = slugify(database_id);

        // Verify original connection exists
        if (!connectionsMap.has(originalDatabaseId)) {
          console.warn(
            `[mergeConnections] Update skipped: Original connection "${originalDatabaseId}" not found`
          );
          break;
        }

        // Check for name conflict (excluding the one being updated)
        if (newId !== originalDatabaseId && connectionsMap.has(newId)) {
          console.warn(
            `[mergeConnections] Update skipped: New name "${newId}" conflicts with existing connection`
          );
          break;
        }

        // Remove old and add updated connection
        connectionsMap.delete(originalDatabaseId);
        connectionsMap.set(newId, {
          engine,
          database_id: newId,

View on GitHub (pinned to 20f6d3546c)

Solutions

List the current connections (the env/system setting backing the map) and re-issue the update using the existing id.
If the goal is rename, ensure the original id still exists or recreate the connection under the new name.
Refresh the admin UI before editing so it submits current ids, not stale ones.
Avoid concurrent connection edits; serialize config changes.

Defensive patterns

Strategy: validation

Validate before calling

// Before submitting an update, confirm the original id still exists:
const current = await fetchConnectionsFromSettings();
const ids = new Set(current.map((c) => c.id));
if (!ids.has(originalDatabaseId)) {
  throw new Error(`connection "${originalDatabaseId}" no longer exists — refresh and retry`);
}

Type guard

function connectionExists(connectionsMap, id) {
  return typeof id === 'string' && connectionsMap.has(id);
}

Prevention

Reload the connections list in the UI before editing to avoid stale ids.
Serialize connection edits — never merge concurrently.
When renaming, do the rename first, then update by the new id in a separate pass.
Log the surviving connection ids after each merge to catch drift early.

When it happens

Trigger: The connection was renamed or removed in an earlier merge pass, then an update referencing the old id arrives; slugify(database_id) produced a different id than the stored key; two concurrent config updates where one deleted the entry first; stale UI submitting an outdated connection id.

Common situations: Editing vector DB connections across multiple tabs/sessions; automation scripts updating by a name that was already renamed; leftover references after migrating connection ids.

Related errors

AI-assisted analysis of Mintplex-Labs/anything-llm@20f6d3546c (2026-08-18). Data as JSON: /api/errors/8fc15ed8d64dac34. Report an issue: GitHub.