sfdx force:source:push fails with Duplicate name <some metadata> error on 7.145 & 7.144.2

[yk92]

Summary

After recently upgrading my sfdx cli version (yesterday) via NPM I am no longer able to run sfdx force:source:push - The command ends in an error about duplicate metadata every single time.

Steps To Reproduce:

Repository to reproduce: dreamhouse-lwc

Did not try this here but I did confirm that any version greater than 7.143 throws errors on a source push. As soon as I downgraded using npm i [email protected] the issue went away

1. Install latest release sfdx-cli
2. sfdx force:source:push your codebase

Expected result

Push completes successfully

Actual result

Push errors out with duplicate metadata errors as seen on this ticket

System Information

SFDX version 7.145 MacOS

Additional information

This looks to be the same exact issue as was reported on this closed issue

[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.

[WillieRuemmele]

Hi @yk92 👋

thanks for reporting this issue. As part of yesterday's release we GA'd the source:beta commands and moved the old source commands to a source:legacy topic. Try using the legacy commands as a workaround while we investigate this issue. If the legacy commands work, please let us know.

It seems like there's some fixes mentioned in that GH issue. I would suggest trying those to see if they fix your project too

[yippie]

You are hitting the notes here https://github.com/forcedotcom/cli/blob/main/releasenotes/sfdx/README.md#71400-march-3-2022

The beta push/pull was put into prod in 7.144 . Basically it now combines all the folders and does a single push by default. This seems to never work and the fix is to add "pushPackageDirectoriesSequentially": true to your sfdx-project.json to make it push sequentially.

[yk92]

Guys, thanks so much! The one time we dont look at release notes we get crushed... Appreciate the quick replies. Have a great weekend

[Saauan]

Hello ! I have a similar issue (same error message). However, the workaround of pushing the directories sequentially does not work for me as I only have one package directory. For now I'm going to use the legacy push and pull, but is there a fix coming about this issue ?

[WillieRuemmele]

Hi @Saauan 👋

if you are able to find steps to reproduce we'd love to investigate and fix this. If you can recreate the issue I'd suggest creating a new issue so we can track it there.

I'd also suggest verifying that the setting is spelled correctly and everything is set up correctly

[toddhalfpenny]

Hi @WillieRuemmele ,

Thought I'd jump in here to say that I'm seeing the issue mentioned above.
In my case we have 3 packages (and an unpakcaged dir) in a project, and the sfdx force:source:push is failing with an error like this;

=== Component Failures [4]

 Type  Name         Problem                                 
 ───── ──────────── ─────────────────────────────────────── 
 Error <custom_object> Duplicate name '<custom_object>' specified 
 Error <custom_object>Duplicate name '<custom_object>' specified 
 Error <custom_object> Duplicate name '<custom_object>' specified 
 Error <custom_object> Duplicate name '<custom_object>' specified 

In this case the <custom_object> error is repeated 4 times (perhaps linked to the number of directories?)

Oh, I should say that I see this error even if I have the "pushPackageDirectoriesSequentially": true in my sfdx-project.json

If I use the force:source:legacy:push then I don't have an issue.

I've replicated this on CLI versions 7.160.0 and 7.168.0.

Happy to assist in the investigation if I can.

[WillieRuemmele]

Hey @toddhalfpenny just trying to understand if this has ever worked since we switched the legacy commands out, or if this is new behavior. Can you provide some steps for us to reproduce the issue?

[toddhalfpenny]

I'm not sure... it's the first time I've been through this process in a while.
I have asked our dev team and the latest version they're on is 7.157.0 (I need to keep on top of that :) )
I'm unsure which version the legacy commands came in on.

From a high level ( and abstracted) PoV our project looks like this;

.
├── src
│   ├── pkg1
│   ├── pkg2
│   ├── pkg3
│   └── unpackaged

And the object that is being complained about is in pkg2

I shall see if I can create a cut-down version of our project and re-produce.

EDIT: I should say that pkg3 is dependant on pkg1 + pkg2, and pkg1 is also dependant on pkg2

[toddhalfpenny]

Looks like #1726 is also similar, I shall move over there.

[toddhalfpenny]

Hi @Saauan, I know this was quite some time ago, but could you confirm if in your case if the error message relates to an object that has RecordType and a field of the same name?

I have this scenario and think I might have found something. My repo had this setup and changing the RT name enabled me to push. Looks like this might also be the case in #1726

[Saauan]

Hello @toddhalfpenny. I'm going to be very honest with you, I am not working for the company where I had this bug anymore, and I don't remember any detail about the bug. I don't even remember if I found what caused the issue or not. So I'm truly sorry.. I should have wrote a nice bug report back then

[toddhalfpenny]

No worries... maybe I need to swap jobs to get this bug out of my life 😉
I hope I'm targeting in on a repo that can reproduce this.

[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.

[Saauan]

@toddhalfpenny, the issue with the duplicate recordType seems oddly familiar to me. I think you're homing in on the right thing. Good luck !