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 test-vm9jlqkus3h1@example.com 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.