Troubleshoot Import and Apply Errors Beta

This guide covers common validation and error scenarios when you import workspace resources into a CLI project or run apply afterward.

Project has changes to be synced

The import workspace command fails with the following error:

Error: import not allowed as project has changes to be synced

What it means: Before it imports anything, Rudder CLI compares your local project with the resources in the workspace that are already CLI-managed. The import runs only when the two match, that is, when apply would have nothing to do. Any difference blocks it:

• Resources in your project that don’t exist in the workspace yet
• Resources whose settings in your project differ from the workspace
• CLI-managed resources in the workspace that your project doesn’t contain

Differences in secret values alone don’t block the import.

Common causes

• The workspace already has resources managed by another CLI project. This is the usual cause when you run the import from a new or empty directory. Your project contains none of those resources, so they count as pending deletions. The import never re-imports resources that a project already manages, so there’s no way to import them into a second project.

• Your project has changes you haven’t applied yet, or someone changed CLI-managed resources outside Rudder CLI.

• Your specs use {{ .VAR }} references and you didn’t pass --var-file. Without the var file, import workspace can’t resolve those references when it reads the project, so the affected fields read as changes. Rudder CLI v0.26.0 and later accept --var-file on import workspace. Pass the same var file you use with apply:

  bash Copy

  rudder-cli import workspace -l <project-directory> --var-file ./secrets.vars.yaml

  On v0.25.1 and earlier, import workspace has no --var-file flag. Upgrade Rudder CLI.

Don’t run apply just to clear this error. If you run it from an empty or partial project, apply deletes every CLI-managed resource in the workspace that the project doesn’t contain.

Fix:

1. See what differs. A dry run shows the plan without changing anything:

   bash Copy

   rudder-cli apply -l <project-directory> --dry-run

   Resources under Removed resources are CLI-managed in the workspace but missing from your project. apply would delete them.

2. If Removed resources lists resources that this project didn’t create, another CLI project owns them. Find the Git repository that holds that project and run import workspace from there, so a single project manages the whole workspace. See One project per workspace. If you can’t find that project, contact RudderStack support before you run apply.

3. If the plan shows only changes you intend to make, such as specs you added or edited in this project, apply them and then run import workspace again.

Imported directory already exists

If an imported directory already exists in your project, the import workspace command will fail with the following error:

Error: directory for import: my-project/imported already exists

Fix: Move anything you need out of imported/, delete the imported directory, and run import workspace again.

Import fails with “file exists” for transformation code

The import workspace command fails with an error like:

Error: writing files for formattable entities: writing my-project/imported/transformations/javascript/<name>.js: opening file ... file exists

Cause: A transformation and a transformation library in the workspace use the same language and have the same name. Names that differ only in case, spaces, or punctuation, such as My Utils and my-utils, count as the same. Import tries to write both code files to the same path. This is a known issue in Rudder CLI v0.25.1 and earlier.

Fix: Upgrade to a Rudder CLI release that includes the import file-name dedupe fix, where import renames the second file automatically. On v0.25.1 and earlier:

1. In the RudderStack dashboard, rename the transformation or the library so the names differ. If you rename the library, make sure its import name, which transformation code uses to import it, doesn’t change.
2. Delete the partially written imported directory.
3. Run import workspace again.

Import fails for a specific resource

When import workspace or a resource-specific import fails:

• Confirm the workspace still contains the remote_id you’re importing
• Confirm your token includes the required permissions for that resource type
• Make sure the local_id doesn’t conflict with an existing CLI-managed resource

Apply fails after import

When apply fails right after an import:

• Check that every generated YAML file is present and valid
• For SQL models you imported with --sql-location, keep the YAML and the referenced .sql file on the paths Rudder CLI expects
• Confirm you’re logged in and the token can reach the workspace
• Confirm that no manual changes were made to the resource in the RudderStack dashboard after import — if changes were made outside Rudder CLI, you will be prompted to reconcile them

Resource deleted from dashboard before apply

If you delete a resource from the RudderStack dashboard after running import workspace but before running apply, the apply command will fail with:

Resource with ID not found

Fix: Remove the matching YAML from the project (or rewrite it so Rudder CLI creates a new resource), then run apply again.