Org Browser unable to retrieve GlobalValueSet

[49FD7E1E1F]

Summary

Org Browser can't retrieve any GlobalValueSets.

Steps To Reproduce:

1. Have/create a Picklist Value Set
2. Connect to Org in VSCode
3. Open Org Browser
4. Go to GlobalValueSet category
5. Press any of the two buttons to retrieve it

Expected result

Retrieve the selected GlobalValueSet metadata.

Actual result

Fails to retrieve. VSCode "Salesforce CLI" Output panel shows:

Starting SFDX: Retrieve Source from Org

=== Retrieve Warnings
FULL NAME               TYPE            MESSAGE                                                                       
──────────────────────  ──────────────  ──────────────────────────────────────────────────────────────────────────────
Review_Root_Cause__gvs  GlobalValueSet  Entity of type 'GlobalValueSet' named 'Review_Root_Cause__gvs' cannot be found

ended SFDX: Retrieve Source from Org

Additional information

The problem is probably from the __gvs suffix being included in the request fired by the Org Browser. I say this because attempting to retrieve using the CLI is successful when omitting the suffix:

PS > sfdx force:source:retrieve -m GlobalValueSet:Review_Root_Cause__gvs
Preparing retrieve request... done
=== Retrieved Source

No results found
=== Retrieved Source Warnings

 FILE NAME              PROBLEM
 ────────────────────── ──────────────────────────────────────────────────────────────────────────────
 unpackaged/package.xml Entity of type 'GlobalValueSet' named 'Review_Root_Cause__gvs' cannot be found

PS > sfdx force:source:retrieve -m GlobalValueSet:Review_Root_Cause
Preparing retrieve request... done
=== Retrieved Source

 FULL NAME         TYPE           PROJECT PATH
 ───────────────── ────────────── ────────────────────────────────────────────────────────────────────────────────
 Review_Root_Cause GlobalValueSet force-app\main\default\globalValueSets\Review_Root_Cause.globalValueSet-meta.xml
PS > 

Salesforce Extension Version in VS Code: 55.8.0

SFDX CLI Version: 7.165.0

OS and version: Windows 11 Pro, Version 21H2, Build 22000.856

Screenshots

How it shows up in the Org Browser:

How the Picklist Value Set looks in the org:

Demonstrating __gvs can't be something named by the user:

[klewis-sfdc]

Hi @49FD7E1E1F,

Thanks for reporting the issue. When I create a global value set and retrieve it via Org Browser on a machine running macOS it works right now.

Is the value set being retrieved named with a double underscore on the server? Does the retrieval work if the name of the global value set is modified to remove the double underscore? The CLI might be splitting on the double underscore, interpreting it as a delimiter for the namespace.

[49FD7E1E1F]

ℹ️ Issue updated: more details, screenshots

Hi @49FD7E1E1F,

Hello, @klewis-sfdc, thanks for responding.

on a machine running macOS it works right now.

Interesting; I didn't expect the OS to make a difference.

Is the value set being retrieved named with a double underscore on the server?

Assuming this means looking at its details in the org through the web browser, then no (see screenshot).

Does the retrieval work if the name of the global value set is modified to remove the double underscore?

It works, as demonstrated when manually retrieved using the terminal, and omitting that ending. I've update the example to include attempts with both namings.

The CLI might be splitting on the double underscore, interpreting it as a delimiter for the namespace.

1. If the CLI means the terminal, there's no splitting there; as you see it in my example, it will attempt to get with __gvs if that's what you wrote.

2. If the CLI means the Org Browser/extension etc.: namespaced GVS don't show up in the Org Browser at all (nothing namespaced does), so why would it bother with that? Even if it did, I do want it to split out the __gvs part so I don't think it does what you're saying; as you see in Output 'Review_Root_Cause__gvs' cannot be found so there wasn't anything split, right?

Your questions made me realise I could do some more explaining, therefore I've update the issue with more details, and also some screenshots. Hope it helps!

[klewis-sfdc]

@49FD7E1E1F Thank you for the additional detail and screenshots! Very helpful. It looks like this issue might be caused by this change in the Winter '23 release. I am working on reproducing the issue locally and will provide an update when I am able to repro.

[klewis-sfdc]

Hi @49FD7E1E1F, Thanks again for providing the additional information. I have been able to spin up a pre-release org on Winter '23 and I am still unable to reproduce this error. When I create a new GlobalValueSet in the org, it does not get a suffix appended and it is successfully retrieved by OrgBrowser. Can you confirm for me that you are still seeing the same issue when creating a brand new GlobalValueSet? Thank you for your patience as I work to repro the issue.

[49FD7E1E1F]

Hi @klewis-sfdc, I am no longer seeing the issue. Global Value Sets (new, or the previous one) no longer show with __gvs ending. However this might have something to do with this change getting pulled from W'23 (at least from release notes), which if true, then this can't be reproduced right now, but it should appear again if/when this change comes again. I guess I should close this, and reopen if/when such time comes?

---

FWIW, my impression is that the bug is maybe a result of the ORG Browser values that show up in the tree structure itself, being used for the SFDX CLI parameters, which lead to problems if SFDX isn't up to date on the metadata changes. For example:

ORG BROWSER
┣ MetadataName
┗━ Some_Dev_Name

⮦ sfdx force:source:retrieve -m MetadataName : Some_Dev_Name

So when __gvs appeared, ORG Browser could see it without problem (Tooling API based I imagine), but SFDX wasn't updated to deal with the now different metadata.

[klewis-sfdc]

Yes, let's re-open if this change gets added back into the next release in the same way and the issue re-appears. Thanks again for all of the additional info while investigating this one.