Deploying project to a new scratch org generate warnings for GlobalValueSet and fail to track them

[hagai-shatz]

Summary

When deploying sfdx project with global value sets to a new scratch org, the command generate some warnings and the global value sets are not properly tracked in the local source tracking in .sf/orgs/<org-id>/maxRevision.josn.

The warnings generated in the first code deployment to a new scratch org:

Deploying v60.0 metadata to [email protected] using the v60.0 SOAP API.
Deploy ID: 0AfPt0000062B5ZKAU
Status: In Progress | ████████████████████████████████████████ | 3/3 Components
Warning: GlobalValueSet, Approval_Statuses__gvs, returned from org, but not found in the local project

When trying to deploy again using sf project deploy start, the global value sets are listed as conflicts:

 STATE    FULL NAME         TYPE           FILE PATH                                                                                                                   
 ──────── ───────────────── ────────────── ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 
 Conflict Approval_Statuses GlobalValueSet /Users/me/MyProject/force-app/main/default/globalValueSets/Approval_Statuses.globalValueSet-meta.xml 
Error (1): There are changes in the org that conflict with the local changes you're trying to deploy.

At this stage, the source code tracking in .sf/orgs/<org-id>/maxRevision.josn has "lastRetrievedFromServer": null for the global value sets:

        "GlobalValueSet__Approval_Statuses": {
            "serverRevisionCounter": 2,
            "lastRetrievedFromServer": null,
            "memberType": "GlobalValueSet",
            "isNameObsolete": false
        },

The conflict can be resolve by forcing a deploy with sf project deploy start --ignore-conflicts, and the source tracking is updated:

        "GlobalValueSet__Approval_Statuses": {
            "serverRevisionCounter": 2,
            "lastRetrievedFromServer": 2,
            "memberType": "GlobalValueSet",
            "isNameObsolete": false
        },

The only clue I can find for this is in the global value set metadata documentation:

Any global value set created in API version 57.0 or later automatically has the __gvs suffix appended to the developer name. When you make any CRUD-based call with the GlobalValueSet type, you must append the suffix to the fullName field when you reference the type.

Steps To Reproduce

Use the following project: https://github.com/hagai-shatz/MyProject

• Create a new scratch org using sf org create scratch -f ./config/project-scratch-def.json --alias test --no-namespace
• Deploy the code using sf project deploy start -o test and see the reported warning
• Try to deploy the code again and see the conflict in the global value set
• Force deploy to resolve the conflict

Expected result

First code deployment to the new scratch org to properly track the version of global value sets.

Actual result

Global value sets fail to be tracked in first deployment of the code.

System Information

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.40.7",
  "nodeVersion": "node-v20.13.1",
  "osVersion": "Darwin 23.4.0",
  "rootPath": "/Users/hagai/.nvm/versions/node/v20.13.1/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.16 (core)",
    "@oclif/plugin-commands 3.3.1 (core)",
    "@oclif/plugin-help 6.0.21 (core)",
    "@oclif/plugin-not-found 3.1.7 (core)",
    "@oclif/plugin-plugins 5.0.18 (core)",
    "@oclif/plugin-search 1.0.23 (core)",
    "@oclif/plugin-update 4.2.9 (core)",
    "@oclif/plugin-version 2.0.17 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.16 (core)",
    "@oclif/plugin-which 3.1.8 (core)",
    "@salesforce/cli 2.40.7 (core)",
    "apex 3.1.11 (core)",
    "auth 3.6.5 (core)",
    "data 3.3.2 (core)",
    "deploy-retrieve 3.6.8 (core)",
    "info 3.2.4 (core)",
    "limits 3.3.4 (core)",
    "marketplace 1.2.4 (core)",
    "org 4.1.5 (core)",
    "packaging 2.4.1 (core)",
    "schema 3.3.4 (core)",
    "settings 2.2.3 (core)",
    "sobject 1.3.6 (core)",
    "source 3.3.5 (core)",
    "telemetry 3.3.4 (core)",
    "templates 56.2.4 (core)",
    "trust 3.6.7 (core)",
    "user 3.5.4 (core)",
    "@salesforce/sfdx-scanner 3.23.0 (user)"
  ]
}

Additional information

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

[iowillhoit]

Hey @hagai-shatz, thanks for the repro repo. I am seeing the same thing. I would guess you are correct that it has something to do with the automatic --gsv suffix on api calls. I'll get a ticket created.

[git2gus]

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

[mshanemc]

fyi about gvs #1933, with a link to a KI (and the internal W- for more context @iowillhoit )

[github-actions]

We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.

[seanhharrison]

Does anyone know how this turned out or if any action was taken?

[dschibster]

Still experiencing the same issue. Has there been any update on the matter @mshanemc? I currently have to advise my devs to basically to double or manual maintenance of global picklists in order to keep my logs smaller.

[mshanemc]

the team that can fix it has not yet.

[fransf-wtax]

Started getting this since a month or two as well. It's super annoying, I basically need to do all my deploys with --ignore-conflicts now which shouldn't be necessary. This is obviously regression; can't the relevant team give this more priority based on that?

I'll log a support ticket for this as well, maybe it helps to add some pressure. Then again, considering we've been waiting for some IdeaExchange ideas for over 10 years, I'm not holding my breath.

[fransf-wtax]

Please add your vote to this known issue.

[cristiand391]

fyi @fransf-wtax
I looked up at the linked case in the work item mentioned in the KI and saw that support said this will be fixed by the CLI...
AFAIK, no one from support reached out to us, the WI is assigned to the owners of the type and haven't been any updates in the last 5 months.

again, this is an API bug and should be fixed by them.

[fransf-wtax]

@cristiand391 That's interesting, thanks for sharing this!

Salesforce support replied with:

This issue will be resolved as a part of Salesforce CLI, and unfortunately there is no ETA on this. We totally apologize for the time consumption of this issue and the inconvenience caused to you.

But what you're saying is this is a bug in the API and needs to be fixed there.

I'll relay this to the support person. I'll ask him to keep the case open until they get more clarity on this. Maybe that'll force the API team to talk to you / the CLI team and come to an agreement on where the problem lies so that it actually gets fixed because it seems like the current situation is a stalemate.

Will update this ticket as I get responses from Salesforce support.

[fransf-wtax]

Latest update from Salesforce support:

I have got an update from the product owner that this bug will fixed in later releases, as there is no
ETA as of now. The team is working on most high priority tasks now, and once they have done, they
will prioritise this issue and fix this.

I've responded that the bug was logged 5 months ago, so Salesforce have already had 5 months to work on "high priority tasks" and it's about time they started working on this bug. Waiting for a response...

[fransf-wtax]

Latest from Salesforce Support is that the fix for this is "tentatively planned in the second half of" 2025 as a patch/fix ("safe harbor"). So I guess we're all out on the stormy sea until then.

Looks like they just introduced this new __gvs suffix without properly assessing all the knock-on effects it would have. And now that the bug reports are coming in they're not even giving them priority. Very poor engineering and customer service on Salesforce's part.