sfdx force:source:push failing with duplicate objects

[deb761]

Summary

I've tested this with multiple versions of the cli. Package has multiple projects, but no repeats of the metadata within them.

currently: sfdx-cli/7.169.1 darwin-x64 node-v16.15.0

{
    "packageDirectories": [
        {
            "path": "force-app",
            "default": true
        },
        {
            "path": "scratch-config",
            "default": false
        },
        {
            "path": "unpackaged/pre",
            "default": false
        }
    ],
    "namespace": "atlas1",
    "sfdcLoginUrl": "https://login.salesforce.com",
    "sourceApiVersion": "55.0",
    "pushPackageDirectoriesSequentially": true
}

Output:

                    === Component Failures [4]                                  
                                                                                
                     Type  Name          Problem                                
                     ───── ─────────────                                        
                    ────────────────────────────────────────                    
                     Error Log__c.Client Duplicate name 'Log__c.Client'         
                    specified                                                   
                     Error Log__c.Client Duplicate name 'Log__c.Client'         
                    specified                                                   
                     Error Log__c.Client Duplicate name 'Log__c.Client'         
                    specified                                                   
                     Error Log__c.Client Duplicate name 'Log__c.Client'         
                    specified                                                   

I may have had a hidden file allowing me to push successfully, because when I cleaned out my directory, git clean -ffdx, I was able to reproduce what I have been seeing in github actions and my colleague has been seeing on windows.

Steps To Reproduce:

Repository to reproduce: atlas-dogs

NOTE: If your issue is not reproducable by dreamhouse-lwc, i.e. requires specific metadata or files, we require a link to a simple Salesforce project repository with a script to setup a scratch org that reproduces your problem.

1. create a scratch org.
2. run sfdx force:source:push to the scratch org.

Expected result

Source should have deployed to the scratch org.

Actual result

Describe what actually happened.

System Information

{
  "cliVersion": "sfdx-cli/7.169.1",
  "architecture": "darwin-x64",
  "nodeVersion": "node-v16.15.0",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 1.3.0 (core)",
    "@oclif/plugin-commands 2.2.0 (core)",
    "@oclif/plugin-help 2.2.3 (user)",
    "@oclif/plugin-not-found 2.3.1 (core)",
    "@oclif/plugin-plugins 2.1.0 (core)",
    "@oclif/plugin-update 1.3.10 (user)",
    "@oclif/plugin-version 1.1.2 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.4 (core)",
    "@oclif/plugin-which 2.1.0 (core)",
    "@salesforce/lwc-dev-server 2.10.0 (user)",
    "alias 2.1.0 (core)",
    "apex 1.2.0 (core)",
    "auth 2.2.5 (core)",
    "community 2.0.1 (core)",
    "config 1.4.19 (core)",
    "custom-metadata 2.0.0 (core)",
    "data 2.1.2 (core)",
    "generator 2.0.2 (core)",
    "info 2.1.0 (core)",
    "limits 2.0.1 (core)",
    "org 2.2.3 (core)",
    "packaging 1.9.1 (core)",
    "schema 2.1.3 (core)",
    "signups 1.2.0 (core)",
    "source 2.0.13 (core)",
    "telemetry 2.0.0 (core)",
    "templates 55.1.0 (core)",
    "trust 2.0.4 (core)",
    "user 1.4.0 (user)",
    "@salesforce/sfdx-plugin-lwc-test 1.0.1 (core)",
    "salesforce-alm 54.8.1 (core)"
  ],
  "osVersion": "Darwin 21.6.0",
  "shell": "bash",
  "rootPath": "/usr/local/lib/node_modules/sfdx-cli"
}```
### Additional information

_Feel free to attach a screenshot_.

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[toddhalfpenny]

Ah... think I might be onto something.
I was also seeing this in a multi-dir setup (though that might be a red herring)... In your repo (and mine) I see that the error relates to <Object>.<xxx>, and in both cases the <xxx> relates to RecordType and a field name.

@deb761 Do you think you could attempt to push to a new scratch again but beforehand change the name of the RecordType to Log__c.ClientRT (or something)?
I did this in my repo and was able to push successfully.

[toddhalfpenny]

OK, so I'm a plum.
We had 2 MyObject.recordType-meta.xml files in our project... one was hiding in the compactLaouts folder for some reason.
I might see if I can look at plugin-source to see if further details can be provided in the Duplicate errors.

[mshanemc]

I'm not able to repro this because of the namespace issues (can't create a scratch org with your namespace, looks like you've got code that has that namespace in it).

We've also deprecated the push command in favor of running project deploy start multiple times. If your duplicate code was a result of there actually being duplicates, then that should allow things to be deployed multiple times

[erocheleau]

Hey @mshanemc I know this was closed but I'm also in the same situation.

For reference we have a bunch of custom labels that we had already deployed in an organization (not a scratch org) via the project convert source followed by the project deploy start --metadata-dir command.

Now we moved the labels-meta.xml file to a different sub-directory inside force-app.

And when we try to redeploy, using the same two step process of source convert followed by the project deploy start, we get a "duplicate name" on all of the labels contained in the labels-meta.xml file.

When I try the exact same steps in a scratch org however, it doesn't create the issue, even after moving the file, the labels deploy with a mark as "Unchanged". I am thinking that's because a scratch org might have better file tracking than the "regular" organization?

If you have a suggestion, I would take it. Otherwise I'm still experimenting and will try to update if I find a solution.

[mshanemc]

@erocheleau my theory is that tracking is handling what you really need (moving a label is the equivalent of creating one and deleting another).

If that's true, then you should be able to deploy that moved label using project deploy start with some destructive-changes (pre, I thinkj) to delete the old name before deploying the new one.

[erocheleau]

I would like to try that yes I had that in my list of ideas, unfortunately these labels are managed in a package in the org I'm trying to deploy to.

I think? it wouldn't let me do that then because they are managed no? AKA you can't delete a managed label it looks like so unless the destructive-changes pre follow different rules it wouldn't work?

What I'm reading between the lines of your answer is that essentially moving the labels is not something we CAN do? Since it's equivalent essentially as delete + create?

Is there no way of saying that these are the same labels as before, just overwrite the existing ones instead of trying to create new ones?

Update: I have tried the same process with a scratch org that I created with the --no-track-source and it still goes through no problem deploying the labels a 2nd time after moving them from one folder to another folder.

Our folder structure looked like this before:

force-app/
    someFolder <-- where the labels were before
    main/default 

And now it looks like this:

force-app/
    main/
         someFolder/someOtherFolder/anotherFolder <-- where the labels are now
    default/

[mshanemc]

yeah, that sounds right. I'm guessing your sbox has the managed package in there, but the scratch org doesn't? So the scratch org thinks you're managing stuff that belongs to you and the sbox knows you're not.

[I'd advise against managing source you don't own]

[erocheleau]

Not sure I understand, this is all code we manage, we've just split it in sub-folders to make more sense.

I confirmed that it's not the "location" of the file that is causing issues afaik,

Since we run project convert source before deploying, everything gets flatten into a single folder, and the problematic labels are just under <root>/labels as expected.

What I've found so far is that the result of the project convert source in the generated folder, inside the package.xml. It generates both a section for

<types>
    [...] All the specific labels name
    <name>CustomLabel</name>
</types>
<types>
    <members>CustomLabels</members>
    <name>CustomLabels</name>
</types>

So all the specific labels are in the first "CustomLabel" type, even if they are all in the same CustomLabels.labels file.
And then it looks like the 2nd type just says "include all custom labels",

I believe this is what is creating the duplicate error. But I still can't figure out why this gets duplicated like this. I just run the command, and I don't modify anything in the resulting package.xml file. So is that a bug in the code that generates the package.xml when you run the project convert source ?

[erocheleau]

Oh wow, I figured out what the problem was, we DID have duplicate labels in the code generated on our CI, and when running project convert source it was merging the multiple labels all in one file, creating multiple entries for the same labels.

I know it's our fault, but it's also the only metadata type we had where it did that. All the other LWCs, Apex classes, etc. etc. all didn't get duplicated even if we had multiple copies of the same files in our source code when running the project convert source command.