Upgrading from 3.4.11 to latest version can brick projects because of step name duplication

Shogan's Avatar


08 Nov, 2017 06:19 PM

I just upgraded a clone of my production instance, and everything went well until I tried to edit the steps in an existing project.

We have some steps with the same name, (but different case / capitilization). When I try to edit the project or steps, I get an error that the update can't be made because there are steps with duplication.

There was no validation in 3.4.11 when users created these steps with different case sensitivity. I guess they encountered validation errors when using the exact case, but then changed the capitilization to get around that...

So now, the project cannot be changed - I've tried deleting the steps, modifying their names, but I always get a validation error no matter what. Even went as far as using the REST API to adjust the duplicated steps, but that also errors out.

This can essentially brick an entire project, (or is there a way I can manually forward fix this?)

I guess there should be some validation run when users upgrade Octopus from older versions that didn't have exact case validation in place. I see a ticket open that handles this exact issue, but I guess the fix must have been just to prevent the creation of objects with duplicate names in the first, place, but doesn't handle cases where those may already be in place.

Issue I refer to: https://github.com/OctopusDeploy/Issues/issues/3713

Attached screenshot showing example of the validation error I now get in the newly upgraded instance.

Do you know of a way I can forward fix this, without having to restore a backup of my pre-upgraded instance and start all over again?

  1. Support Staff 1 Posted by Cameron MacFarl... on 10 Nov, 2017 07:42 AM

    Cameron MacFarland's Avatar

    Hi Shogan,

    Sorry to hear you're having problems upgrading. Currently we don't have a good way of dealing with changes like that without breaking things.

    In your situation the problem is coming from the deployment steps having a child action and that child action also has the same name. Here's an example JSON of a deployment process.

      "Id": "deploymentprocess-Projects-1",
      "ProjectId": "Projects-1",
      "Steps": [
          "Id": "6405c7f3-ec1f-44e9-a5bc-2d336f40667e",
          "Name": "Deploy The Package",
          "RequiresPackagesToBeAcquired": false,
          "Properties": {
            "Octopus.Action.TargetRoles": "Test"
          "Condition": "Always",
          "StartTrigger": "StartAfterPrevious",
          "Actions": [
              "Id": "f822d4e1-b08d-4e56-b54b-bbc10b00019e",
              "Name": "Deploy The Package",
              "ActionType": "Octopus.TentaclePackage",
              "IsDisabled": false,
              "Environments": [],
              "ExcludedEnvironments": [],
              "Channels": [],
              "TenantTags": [],
              "Properties": {
                "Octopus.Action.Package.AutomaticallyRunConfigurationTransformationFiles": "True",
                "Octopus.Action.Package.AutomaticallyUpdateAppSettingsAndConnectionStrings": "True",
                "Octopus.Action.EnabledFeatures": "Octopus.Features.ConfigurationTransforms,Octopus.Features.ConfigurationVariables",
                "Octopus.Action.Package.DownloadOnTentacle": "False",
                "Octopus.Action.Package.FeedId": "feeds-builtin",
                "Octopus.Action.Package.PackageId": "ThePackage"
              "Links": {}
      "Version": 5,
      "LastSnapshotId": null,
      "Links": {
        "Self": "/api/deploymentprocesses/deploymentprocess-Projects-1",
        "Project": "/api/projects/Projects-1",
        "Template": "/api/deploymentprocesses/deploymentprocess-Projects-1/template{?channel,releaseId}"

    To fix using the REST api you have to rename the deployment step as well as the child action.

    Hope that helps.

  2. 2 Posted by Shogan on 19 Nov, 2017 01:08 AM

    Shogan's Avatar

    Hi Cameron,

    Thanks for that. I see - I was previously attempting to use the REST API, but didn't realise the nested child actions had duplicate names as well as the actual deployment steps themselves, so I wasn't trying to change those too.

    I modified my script to change all three duplicate steps and duplicate child action names to names with GUIDs added, and sent that up to the deployment process in question via the API which did the trick.

    I also changed these steps in the production instance (old version) before upgrading, to avoid this issue in production after the actual upgrade, and this worked well to avoid the problem after the upgrade.

    Everything else on the upgrade went flawlessly too. Hopefully this thread comes in handy for anyone else who might potentially run into this problem/snag of upgrading an old version to a newer version where the validation of step names has been fixed to validate while taking lower vs upper case differences into account :)

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Already uploaded files

  • example.png 22.4 KB

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac