"Component conversion failed: group.push is not a function" errror when running force:source:deploy

[gsbasso]

Summary

This is another example of an issue related to the 7.112 update. After trolling through the commentary for other, similar issues I have actually identified and resolved the issue but I thought it might be helpful to others if I reported my particular experience. Plus I wanted to rant a little. First the rant...

So this is yet another example of a surprise change with no advance warning that has broken existing functionality (literally the command worked one day with the 7.110 release and then the next day the exact same command was failing, which, after some initial trouble-shooting, we realized was a result of a CLI update). In my world something that worked one day and then begins to fail after some sort of update is considered a bug. Fine you are now trying to enforce things you have been allowing until now, but this could have been handled a lot better.

How could it have been handled better? Why not write out a notice every time an sfdx command is run? You've done this before for other upcoming changes. And how about some option to test out the current source structure in advance of the official change to identify any potential problems? Related to that, how about returning some helpful error messages? The error message that we were seeing is completely unhelpful. Now on to the actual issue...

Basically we were attempting to deploy the source of a custom object. Within the object-meta source we had the following content:

<fields>
    <fullName>OwnerId</fullName>
    <trackHistory>true</trackHistory>
</fields>

As you might guess we are enabling history tracking on the Owner system field. The solution (workaround?) was to remove the above content from the object-meta file and create an actual OwnerId.field-meta.xml file under the fields sub-folder of the custom object.

It's worth pointing out that in terms of the documented schema fields elements are perfectly legal/allowed as part of a custom object definition. And this has been allowed/supported up until now.

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. In any object-meta source file for a custom object add the above fields content to enable history tracking for the Owner system field
2. Run the command: sfdx force:source:deploy -u <alias> -m CustomObject:MyObject__c
3. Note that unlike other issues that have been reported we get the same error using the -p parameter instead of -m

Expected result

Deploy succeeds (and was succeeding with the 7.110 release).

Actual result

Command fails with the error: Component conversion failed: group.push is not a function

As previously noted the error is entirely unhelpful.

System Information

    "cliVersion": "sfdx-cli/7.112.1",
    "architecture": "win32-x64",
    "nodeVersion": "node-v14.17.4",
    "pluginVersions": [
            "@oclif/plugin-autocomplete 0.3.0 (core)",
            "@oclif/plugin-commands 1.3.0 (core)",
            "@oclif/plugin-help 3.2.2 (core)",
            "@oclif/plugin-not-found 1.2.4 (core)",
            "@oclif/plugin-plugins 1.10.1 (core)",
            "@oclif/plugin-update 1.4.0-3 (core)",
            "@oclif/plugin-warn-if-update-available 1.7.0 (core)",
            "@oclif/plugin-which 1.0.3 (core)",
            "@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)",
            "@salesforce/sfdx-trust 3.6.0 (core)",
            "alias 1.1.10 (core)",
            "apex 0.2.3 (core)",
            "auth 1.7.1 (core)",
            "config 1.2.14 (core)",
            "custom-metadata 1.0.12 (core)",
            "data 0.6.0 (core)",
            "generator 1.1.7 (core)",
            "limits 1.2.1 (core)",
            "org 1.6.7 (core)",
            "salesforce-alm 52.2.3 (core)",
            "schema 1.0.8 (core)",
            "sfdx-cli 7.112.1 (core)",
            "source 1.0.6 (core)",
            "telemetry 1.2.3 (core)",
            "templates 52.1.0 (core)",
            "user 1.4.0 (core)"
    ],
    "osVersion": "Windows_NT 10.0.18363"

Additional information

As noted, to resolve simply create a field-meta file for the system field under the fields sub-folder.

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

[mshanemc]

Thanks for digging past the weak error message to identify the real cause of the error. Did you manually create that field in the object-meta.xml or was it the result of a source:retrieve or the result of converting a mdapi:retrieve?

Thanks also for the comms feedback--we're hearing that "in-CLI messaging" is the best way to get more attention and preview testers. We've historically used GitHub (this announcement was pinned for about 6 weeks prior to the change #1057) and the release notes to communicate changes and early testing of new plugin changes.

[uip-robot-zz]

This issue has been linked to a new work item: W-9747902

[gsbasso]

Our developer informs me they manually modified the object-meta file. But I don't believe you can retrieve history tracking for system fields. Perhaps Owner because you can set this in the setup UI but certainly not for something like LastModifiedBy.

For the record, the field-meta we used was as follows:

<?xml version=".0" encoding="UTF-8"?>
<CustomField xmlns="http://soap.sforce.com/2006/04/metadata">
    <fullName>OwnerId</fullName>
    <encryptionScheme>None</encryptionScheme>
    <trackFeedHistory>false</trackFeedHistory>
    <trackHistory>true</trackHistory>
</CustomField>

[mshanemc]

@gsbasso thanks for the reproduction help. I found the error in the SDR library, so the fix should be in the RC on Thursday, into the "main" for next Thursday.

I'd suggest using your workaround in the meantime, but it'll work both ways once this gets released.

[WillieRuemmele]

Hi @gsbasso this should be fixed in the latest-rc build of the cli 1.115.0, you can get it by either sfdx update stable-rc or npm install sfdx-cli@latest-rc --global depending on your preferred install method.

Please let us know if you're still seeing this in 1.115.0 of the CLI