VS Code drops leading zero in picklist field metadata values in a sandbox

[davidchengIC]

Summary

I'm seeing picklist metadata problems with VS code and a regular sandbox (not a scratch org). I have a picklist where some values have leading zeros, e.g. "01", "02", etc. When I retrieve the field's metadata, the leading zero has been dropped in both the label and full name. Example: instead of "01" I get "1":

I need to commit and deploy this metadata with the leading zero.

Steps To Reproduce:

1. Create a project with a manifest.
2. Connect to a sandbox.
3. Create a picklist field in any object and set values to "01", "02", "03" etc
4. In VS Code, use the org browser to retrieve the metadata for the object.
5. Examine the picklist field you created.

Expected result

<type>Picklist</type>
<valueSet>
    <valueSetDefinition>
        <sorted>false</sorted>
        <value>
            <fullName>01</fullName>
            <default>false</default>
            <label>01</label>
        </value>

Actual result

<type>Picklist</type>
<valueSet>
    <valueSetDefinition>
        <sorted>false</sorted>
        <value>
            <fullName>1</fullName>
            <default>false</default>
            <label>1</label>
        </value>

Additional information

VS Code Version: 1.55.1

SFDX CLI Version: sfdx-cli/7.93.1-762bca056d darwin-x64 node-v14.15.4

OS Version: Mac OS X 10.15.7

NOTE: I tried on a second machine with earlier versions of VS Code and SF Extension Pack -- it worked correctly. (I didn't make a note of the earlier version numbers.) When I updated VS Code and SF Extension to the latest version, then the leading zeros are omitted when the metadata is retrieved again.

[vincentducorps]

I was writting the same issue...

There is a workaround :

• Select File > Preferences > Settings (Windows or Linux) or Code > Preferences > Settings
• Disable : Salesforcedx-vscode-core › Experimental: Deploy Retrieve

TO MAINTAINERS : Please warn users when you set an experimental feature to on by default...

[davidchengIC]

Thank you @vincentducorps, that solved the problem.

[sfsholden]

Reopening - this looks like a bug we need to address within the new experimental deploy retrieve.

@vincentducorps
We did have a pinned issue to announce the default changing here - #3109.

It sounds like going forward we should use a different approach. Do you feel a one time dialog popup would have been better? We appreciate the honest feedback.

[uip-robot-zz]

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

[uip-robot-zz]

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

[GULP-CM]

i think the main issue is that the source-deploy-retrieve module is using the fast-xml-parser with not disabling the parseNodeValues option. So it tries to parse the node values in different kind of types like numbers and so on. i have modified my local version of the file and it works fine:

node_modules/@salesforce/source-deploy-retrieve/lib/src/metadata-registry/sourceComponent.js

from:

parseXml() {
        return __awaiter(this, void 0, void 0, function* () {
            if (this.xml) {
                const contents = yield this.tree.readFile(this.xml);
                return fast_xml_parser_1.parse(contents.toString(), { ignoreAttributes: false });
            }
            return {};
        });
    }

to

parseXml() {
        return __awaiter(this, void 0, void 0, function* () {
            if (this.xml) {
                const contents = yield this.tree.readFile(this.xml);
                return fast_xml_parser_1.parse(contents.toString(), { ignoreAttributes: false, parseNodeValue: false });
            }
            return {};
        });
    }

[brpowell]

Thanks for pinpointing the issue @GULP-CM. We'll work on getting this fix published for next week's release

[brpowell]

Closing since this has been addressed in the latest release (51.11.0)