Budibase/budibase · error · HTTPError

Project import could not remap table for row actions '${doc.

Error message

Project import could not remap table for row actions '${doc._id}'.

What it means

When importing ROW_ACTION documents, the import derives the original table ID from the row action doc ID (extractTableIdFromRowActionsID) and looks it up in the idMap to remap it to the new table ID. This error is thrown when that table was not remapped, so a valid new table ID cannot be generated. The import fails with HTTP 400 because row actions cannot exist without their table.

Source

Thrown at packages/server/src/sdk/workspace/projects/backups/imports.ts:626

      })
    case ResourceType.TABLE:
      return generateTableID()
    case ResourceType.QUERY: {
      const datasourceId = doc.datasourceId && idMap.get(doc.datasourceId)
      if (!datasourceId) {
        throw new HTTPError(
          `Project import could not remap datasource for query '${doc._id}'.`,
          400
        )
      }
      return generateQueryID(datasourceId)
    }
    case ResourceType.AUTOMATION:
      return generateAutomationID()
    case ResourceType.ROW_ACTION: {
      const tableId = idMap.get(extractTableIdFromRowActionsID(doc._id!))
      if (!tableId) {
        throw new HTTPError(
          `Project import could not remap table for row actions '${doc._id}'.`,
          400
        )
      }
      return generateRowActionsID(tableId)
    }
    case ResourceType.WORKSPACE_APP:
      return docIds.generateWorkspaceAppID()
    case ResourceType.SCREEN:
      return generateScreenID()
    default:
      throw new HTTPError(
        `Project import does not support resource type '${resourceType}'.`,
        400
      )
  }
}

View on GitHub (pinned to a81a902e9a)

Solutions

Include the table documents for all row actions in the export package.
Verify row action doc IDs are well-formed so extractTableIdFromRowActionsID yields the correct table ID.
Re-export the project instead of hand-editing package contents.
Strip orphaned row action docs from the package if their tables are intentionally excluded.

Example fix

// before
{ "ROW_ACTION": [{ "_id": "rowactions_table_orphan_abc" }] }
// after (table included so idMap has a mapping)
{ "TABLE": [{ "_id": "table_orphan_abc" }], "ROW_ACTION": [{ "_id": "rowactions_table_orphan_abc" }] }

Defensive patterns

Strategy: validation

Validate before calling

const tableIds = new Set(docs.filter(d => d.type === ResourceType.TABLE).map(d => d._id))
for (const ra of docs.filter(d => d.type === ResourceType.ROW_ACTION)) {
  if (!tableIds.has(extractTableIdFromRowActionsID(ra._id))) throw new Error(`Row action ${ra._id} has no matching table`)
}

Type guard

const hasValidTableRef = (ra: RowAction): boolean => {
  try { return typeof extractTableIdFromRowActionsID(ra._id) === "string" } catch { return false }
}

Try / catch

try {
  await importProjectPackage(file)
} catch (err) {
  if (err instanceof HTTPError && err.status === 400 && err.message.includes("remap table for row actions")) {
    // identify orphaned row action docs from err.message
  }
  throw err
}

Prevention

Never delete tables from an export without also deleting their row actions
Keep row action doc IDs intact when editing packages
Re-export instead of mutating archives

When it happens

Trigger: Importing a package whose row action doc references a table ID not present in the idMap — the table doc was missing from the export, failed to import, or the row action doc _id is malformed so extraction yields a nonexistent table ID.

Common situations: Packages manually edited to remove tables but keep row actions; corrupted or truncated exports; row action docs copied between workspaces.

Related errors

AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29). Data as JSON: /api/errors/03f561f9847071d2. Report an issue: GitHub.