forcedotcom / cli

Salesforce CLI
https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/
BSD 3-Clause "New" or "Revised" License
490 stars 78 forks source link

Error: Metadata API request failed: isomorphic-git error: Index file is empty (.git/index) #3027

Open vgoyal-copado opened 4 days ago

vgoyal-copado commented 4 days ago

Summary

We have a node script using which we are trying to kind of "take a snapshot" of the org. For this,

  1. We create 8 child processes.
  2. All these 8 child processes execute in parallel.
  3. Each process retrieves at max 5000 members of a particular member type.
  4. Each process uses the command sf project retrieve start --target-org <sessionId> --manifest <path-to-package-xml> --wait 60 --json to retrieve a particular member type.
  5. If a process completes a retrieval, it goes on to pick the next metadata type and continues its retrieval

What we observe is: during the retrieval process, some retrievals fail with the error: Metadata API request failed: An internal error caused this command to fail. isomorphic-git error:Index file is empty (.git/index). As far as we have observed, this is happening only for sandboxes and not for regular developer edition orgs.

Steps To Reproduce

In an sfdx-repo ( the size of the repo doesn't matter, I have been trying this on an empty repo ), try to retrieve multiple metadatas in parallel from a sandbox.

Expected result

The metadata retrieval should be successful

Actual result

The metadata retrieval fails with the error: Metadata API request failed: An internal error caused this command to fail. isomorphic-git error:I ndex file is empty (.git/index)

Additional information

System Information

Terminal: bash sf version --verbose --json gives the following response { "architecture": "linux-x64", "cliVersion": "@salesforce/cli/2.52.6", "nodeVersion": "node-v20.15.1", "osVersion": "Linux 4.4.0", "rootPath": "/usr/local/lib/node_modules/@salesforce/cli", "shell": "bash", "pluginVersions": [ "@oclif/plugin-autocomplete 3.1.9 (core)", "@oclif/plugin-commands 4.0.9 (core)", "@oclif/plugin-help 6.2.7 (core)", "@oclif/plugin-not-found 3.2.13 (core)", "@oclif/plugin-plugins 5.3.9 (core)", "@oclif/plugin-search 1.2.4 (core)", "@oclif/plugin-update 4.4.12 (core)", "@oclif/plugin-version 2.2.9 (core)", "@oclif/plugin-warn-if-update-available 3.1.10 (core)", "@oclif/plugin-which 3.2.9 (core)", "@salesforce/cli 2.52.6 (core)", "apex 3.3.2 (core)", "auth 3.6.38 (core)", "data 3.5.8 (core)", "deploy-retrieve 3.9.21 (core)", "info 3.3.21 (core)", "limits 3.3.20 (core)", "marketplace 1.2.19 (core)", "org 4.4.0 (core)", "packaging 2.7.4 (core)", "schema 3.3.21 (core)", "settings 2.3.9 (core)", "sobject 1.4.20 (core)", "source 3.5.7 (core)", "telemetry 3.6.3 (core)", "templates 56.3.6 (core)", "trust 3.7.15 (core)", "user 3.5.20 (core)" ] }

SF CLI Version:  @salesforce/cli/2.52.6 linux-x64 node-v20.15.1
github-actions[bot] commented 4 days ago

Hello @vgoyal-copado :wave: None of the versions of sf you shared match the latest release.

Shared: 2.52.6, 2.52.6 Latest: 2.58.7

Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue. You can also try the rc and nightly releases! (docs)

After updating, share the full output of sf version --verbose --json

github-actions[bot] commented 4 days ago

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.

vgoyal-copado commented 3 days ago

I have updated my sf cli version and I still get this error. This is what the response ofsf version --verbose --json looks like 13:40:14 { 13:40:14 "architecture": "linux-x64", 13:40:14 "cliVersion": "@salesforce/cli/2.58.7", 13:40:14 "nodeVersion": "node-v20.15.1", 13:40:14 "osVersion": "Linux 4.4.0", 13:40:14 "rootPath": "/usr/local/lib/node_modules/@salesforce/cli", 13:40:14 "shell": "bash", 13:40:14 "pluginVersions": [ 13:40:14 "@oclif/plugin-autocomplete 3.2.2 (core)", 13:40:14 "@oclif/plugin-commands 4.0.13 (core)", 13:40:14 "@oclif/plugin-help 6.2.10 (core)", 13:40:14 "@oclif/plugin-not-found 3.2.18 (core)", 13:40:14 "@oclif/plugin-plugins 5.4.6 (core)", 13:40:14 "@oclif/plugin-search 1.2.7 (core)", 13:40:14 "@oclif/plugin-update 4.5.5 (core)", 13:40:14 "@oclif/plugin-version 2.2.11 (core)", 13:40:14 "@oclif/plugin-warn-if-update-available 3.1.13 (core)", 13:40:14 "@oclif/plugin-which 3.2.12 (core)", 13:40:14 "@salesforce/cli 2.58.7 (core)", 13:40:14 "apex 3.4.8 (core)", 13:40:14 "api 1.2.1 (core)", 13:40:14 "auth 3.6.54 (core)", 13:40:14 "data 3.6.5 (core)", 13:40:14 "deploy-retrieve 3.12.3 (core)", 13:40:14 "info 3.4.3 (core)", 13:40:14 "limits 3.3.29 (core)", 13:40:14 "marketplace 1.2.25 (core)", 13:40:14 "org 4.5.7 (core)", 13:40:14 "packaging 2.8.2 (core)", 13:40:14 "schema 3.3.26 (core)", 13:40:14 "settings 2.3.16 (core)", 13:40:14 "sobject 1.4.33 (core)", 13:40:14 "source 3.5.18 (core)", 13:40:14 "telemetry 3.6.10 (core)", 13:40:14 "templates 56.3.17 (core)", 13:40:14 "trust 3.7.27 (core)", 13:40:14 "user 3.5.29 (core)" 13:40:14 ] 13:40:14 }

WillieRuemmele commented 3 days ago

hi @vgoyal-copado - in this scenario, is source-tracking required? you could disable it sf org disable tracking --target-org XXX or with --no-track-source when you create the org.

vgoyal-copado commented 3 days ago

@WillieRuemmele Changing the sandbox is not an option. It's source tracked. I tried sf org disable tracking --target-org XXX but I still get the same error.

WillieRuemmele commented 2 days ago

@vgoyal-copado - this does seem like a bug - we released some fixes around parallelism, but you're on the latest and still seeing issues. I don't see any reason why this would only be happening on sandbox retrieveals, isomorphic-git is a library we use for local source tracking. I'm sure something during the parallel executions is either overwriting, or removing something another process is expecting.

you might be able to add a project reset|delete tracking call after each reset the info. Once the entire batch operation was done, you'd want to reset the tracking to ensure a clean state

git2gus[bot] commented 2 days ago

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