API version in manifest or sfdx-project.json has no impact on retrieve and org explorer

[fishygeek91]

Summary

When retrieving object metadata via the Org Explorer or right clicking on a file, the returned results differ from using force:source:retrieve -x “path/to/package.xml”. This is causing issues for developers who are diffing meta files from production with source control, and is dependent on the way the source is retrieved.

Steps To Reproduce:

1. Used force:source:retrieve -x “path/to/package.xml” to pull test object
2. Next I used the Org Explorer to pull down same object
3. Diff'ed meta. Metadata for object differs
4. Changed API version is package.xml
5. Used force:source:retrieve -x “path/to/package.xml” and source differs from step 1
6. Used Org explorer and received same metadata as step 2.

Expected result

force:source:retrieve -x “path/to/package.xml” returns same metadata as Org Explorer or right clicking on file to retrieve source

Actual result

force:source:retrieve -x “path/to/package.xml” returns different metadata as Org Explorer or right clicking on file to retrieve source

Additional information

https://github.com/forcedotcom/cli/issues/528

Feel free to attach a screenshot.

VS Code Version:

SFDX CLI Version:

OS and version:

[fishygeek91]

Unchecking this box seems to have fixed the issue for me. At least for a test object I have been working with to come up with a solution for our source control.

[smaddox-sf]

Hi @fishygeek91 - Thanks for reaching out. We are working on a fix for this. You are correct on the workaround to uncheck that setting for now. With the setting unchecked, these commands use the CLI directly for these commands vs. the new library for deploy/retrieve. You will see better performance with the library, so I suggest turning this setting back on once we have this fixed. We'll update the issue once we merge a fix.

[uip-robot-zz]

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

[ChuckJonas]

@smaddox-sf could you give us a sense of the timeline for this fix?

We are trying to decide if we should invest in upgrading all of our projects to use the Experimental flag or just waiting for the fix to come out.

Thanks

[brpowell]

Hi @fishygeek91, what are the differences you are seeing in the CustomObject XML? Are they formatting differences, or are actual values in the CustomObject different? If you or @ChuckJonas could provide a screenshot or code snippet example that highlights the difference that would be great. Appreciate it!

[fishygeek91]

@brpowell
Using the CLI might produce:

<actionOverrides>
    <actionName>Accept</actionName>
    <type>Default</type>
</actionOverrides>

but pulling down from the org browser

<actionOverrides>
    <actionName>Accept</actionName>
    <type>Default</type>
</actionOverrides>
<actionOverrides>
    <actionName>Accept</actionName>
    <formFactor>Large</formFactor>
    <type>Default</type>
</actionOverrides>
<actionOverrides>
    <actionName>Accept</actionName>
    <formFactor>Small</formFactor>
    <type>Default</type>
</actionOverrides>

[brpowell]

Looks like the new deploy/retrieve logic does need to respect the SFDX project api version, whether that's resolved from a local or global config when going the source path or org browser route. If you use the manifest deploy/retrieve commands, it respects the version defined in the manifest currently.

@ChuckJonas this should be a relatively easy fix, might be able to get this in for next week's release or the week after.

[sfsholden]

Closing.

This issue should now be resolved as of release v51.12.0.

Thank you for reporting this problem!