sfdx force:source:retrieve behavior changing drastically with minor version change

[BrentHebertZayo]

I'm still filling this out, but I have other work things to address. So I will come through again to fill in more detail.

Summary

When retrieving recordtypes from a sandbox with the sfdx force:source:retrieve -p or -x commands via 7.75 and 7.72 we got totally different results. One came back with "the whole" record type, the other came back with "the minimum".

Steps To Reproduce:

Repository to reproduce: dreamhouse-lwc

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. sfdx plugins:install sfdx-cli@7.72.0
2. sfdx force:source:retrieve -p "file/path/to/any/*.recordType-meta.xml"
3. sfdx plugins:install sfdx-cli@7.75.0
4. sfdx force:source:retrieve -p "file/path/to/any/*.recordType-meta.xml"

Expected result

We should get the same results.

Actual result

7.72 returns the full record type file (~5116 lines). 7.75 returns an incomplete file (~90 lines). Below is the short one.

<?xml version="1.0" encoding="UTF-8"?>
<RecordType xmlns="http://soap.sforce.com/2006/04/metadata">
    <fullName>Agent</fullName>
    <active>true</active>
    <label>Agent / Partner</label>
    <picklistValues>
        <picklist>Industry</picklist>
        <values>
            <fullName>Finance</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Government</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Healthcare</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Religious Institution</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Telecommunications</fullName>
            <default>false</default>
        </values>
    </picklistValues>
    <picklistValues>
        <picklist>Ownership</picklist>
        <values>
            <fullName>Other</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Private</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Public</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Subsidiary</fullName>
            <default>false</default>
        </values>
    </picklistValues>
    <picklistValues>
        <picklist>Rating</picklist>
        <values>
            <fullName>Cold</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Hot</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Warm</fullName>
            <default>false</default>
        </values>
    </picklistValues>
    <picklistValues>
        <picklist>Type</picklist>
        <values>
            <fullName>Billing</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Corporate</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Parent</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Partner</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Prospect</fullName>
            <default>false</default>
        </values>
        <values>
            <fullName>Vendor</fullName>
            <default>false</default>
        </values>
    </picklistValues>
</RecordType>

Additional information

I have found a work around for this change, but it threw all of my users off. Since we are trying to keep our code base version controlled I need my users to be able to commit "the whole" files instead of just partial clumps. The fact that this kind of behavior change was due to a minor version change without warning concerns me for any automation I try to build out going forward. So I want to double check if this is intended behavior, and if so how do I get ahead of it?

SFDX CLI Version(to find the version of the CLI engine run sfdx --version): 7.72 and 7.75

SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core) @oclif/plugin-autocomplete 0.1.5 (core) @oclif/plugin-commands 1.3.0 (core) @oclif/plugin-help 3.2.0 (core) @oclif/plugin-not-found 1.2.4 (core) @oclif/plugin-plugins 1.9.0 (core) @oclif/plugin-update 1.3.10 (core) @oclif/plugin-warn-if-update-available 1.7.0 (core) @oclif/plugin-which 1.0.3 (core) @salesforce/sfdx-diff 0.0.6 @salesforce/sfdx-trust 3.4.3 (core) alias 1.1.2 (core) analytics 1.12.1 (core) config 1.1.8 (core) generator 1.1.3 (core) salesforcedx 49.13.0 (core) ├─ salesforce-alm 49.12.1 (core) ├─ templates 49.9.1 (core) ├─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core) ├─ apex 0.1.0 (core) └─ custom-metadata 1.0.10 (core) sfdx-cli 7.75.0 (core)

OS and version: Mac Catalina

[zerkz]

Are you able to reproduce with 7.76.1 (latest)? I had a ton of issues with the last couple releases that we rolled back our dev-ops deploy bot to 3-4 months old releases.

[BrentHebertZayo]

I was able to have a bunch of users with different versions try it out and I know 7.74.0 up to latest had the same behavior, so I'm guessing that everything after 7.73.0 behaves one way and everything 7.72.0 and earlier behaves the other way.

[frankpeleato]

@BrentHebertZayo what was the workaround you found? I am experiencing a similar issue with the official Salesforce extensions for VS Code.

[BrentHebertZayo]

@frankpeleato I think the easiest workaround is to retrieve the whole object folder if you use the -p flag. So sfdx force:source:retrieve -p "force-app/main/default/objects/yourObject/" worked for us. Otherwise you can always fall back to the -x flag and use a package.xml to get the object.

[frankpeleato]

@frankpeleato I think the easiest workaround is to retrieve the whole object folder if you use the -p flag. So sfdx force:source:retrieve -p "force-app/main/default/objects/yourObject/" worked for us. Otherwise you can always fall back to the -x flag and use a package.xml to get the object.

@BrentHebertZayo Thank you for answering. That is what we have been doing, as well.

[mshanemc]

I'm marking this closed since we changed the library handling deploy/retrieve. If you're still seeing problems with the -x please open a new issue.