# Cross-cutting failure modes

Symptoms that don't fit a single scenario but bite often enough to call out. Use this as triage when you don't yet know which scenario applies.

| Symptom | Likely cause | Fix |
|---|---|---|
| `[1009] <kind> <name>: Invalid argument 'Value'` at deploy | Virtual resource without `value` set ([virtual-resource](virtual-resource.md)) | `deploy config set <file> <name> value <val>` or `deploy config link <file> <name> --name <existing>` |
| Deployment sits in `OperationStatus: Draft` and won't activate | Deploy-time validation rejected a resource; the install never completed | Read the reasons (`Validation:` / `Conflicts:` in the failure's `Instructions` — on every feed, since each deploy waits for its run), fix them with `deploy config set` / `link`, then run the same `deploy run` again with the draft's `--package-version` and `--config-file <file>` — see [A deploy that stops in `Draft`](../pack-and-deploy.md#a-deploy-that-stops-in-draft). `deploy list` shows the row only with the same `--personal-workspace` / `--feed` flag the deploy used |
| `has a pending draft (<key>) for version <v>` from `deploy upgrade` or `deploy run` | An earlier attempt was rejected (`ValidationFailed`, a conflict or scheduling error) and stays behind as a draft that owns the deployment; the live version is untouched | Finish it: re-run the failed `deploy run` with the draft's `--package-version` and a corrected `--config-file`. Or drop it: `deploy upgrade <key> --discard-draft [--version <v>]`, or Delete draft in Orchestrator — see [activate-and-manage](../activate-and-manage.md) |
| `Deploying '<name>' will permanently delete <k> installed resource(s) replaced by links: …` (or `Upgrading …`), `ErrorCode: invalid_argument`, `Data.PermanentDeletionResources` | The config file (`deploy run`) or the new version (`deploy upgrade`) links a resource the deployment already installed; the server deletes the installed copy with its data and asks for consent first. Nothing was installed; the attempt is kept as a pending draft | Not a config error. With the user's consent, re-run the **same** command with `--acknowledge-permanent-deletion` (on `deploy upgrade` never with `--discard-draft`). To keep the copies: `deploy config unlink <file> <resource>` and re-run, or `deploy upgrade <draft-key> --discard-draft` — see [Replacing an installed resource with a link](../pack-and-deploy.md#replacing-an-installed-resource-with-a-link) |
| `deploy uninstall` fails: `Message` "...this deployment has uncompleted jobs; --force uninstalls anyway" or "...permanently deletes these resources and their data: ..." (or the 409 form "Deployment '<name>' was not uninstalled: ..."), `Retry: RetryWillNotFix` | Orchestrator wants consent: jobs not in a final state (`Data.JobsNotInFinalState: true`) and/or installed resources replaced by links that the uninstall deletes (`Data.PermanentDeletionResources`) | Ask the user. Only on explicit consent re-run with `--force` (implies `--yes`); otherwise let the jobs finish and re-run without it -- see [When the uninstall is refused](../activate-and-manage.md#when-the-uninstall-is-refused) |
| `deploy uninstall` fails: "...errors that --force cannot get past: [code] text", `Retry: RetryLater` | The Uninstall validation holds an error `--force` does not skip | Never add `--force`. Resolve the named error in Orchestrator, then run `deploy uninstall <name> --yes` again |
| `Folder already exists` at deploy | `--folder-name` collides with an existing folder under `--parent-folder-path` | Pick a different `--folder-name`, or `solution deploy uninstall <existing>` first |
| Suffix `_N` keeps growing on re-refresh (`_1`, `_2`, `_3`...) | Old CLI version (pre-suffix-amplification fix) | Upgrade `@uipath/cli` to a build that ships the SDK bump (`resource-builder-sdk` ≥ `2025.11.0-alpha3780`); the current refresh is idempotent on cloud key |
| Tool dialog in Studio Web doesn't open for one of two same-name tools | SW UI bug — affects pure-SW solutions too ([same-name-across-folders](same-name-across-folders.md)) | Verified at deploy/runtime — ignore the UI symptom; check the tool resolves correctly via `resources list --source remote` after deploy |
| Refresh imports 0 of N bindings, no warnings | `bindings_v2.json` not at expected path (project root, not nested) | Move file to `<ProjectName>/bindings_v2.json`; `agent validate` regenerates it for agent projects |
| `processKey` collision on `solution publish` | Republishing same name+version | Bump version (`solution pack --version 1.0.1 …`); the feed rejects duplicate `name+version` pairs |

> See the individual scenario files for setup, root-cause walkthroughs, and verification steps.