sf project deploy start is failing or is pending for a very long time

[tanmayythakur]

Note
Before you submit your issue, make sure that:

• You're using the latest version of Salesforce CLI. : @salesforce/cli/2.22.7
• You've searched both open and closed issues for related posts. Yes
• You've used the doctor command to diagnose common issues.
• You understand that GitHub Issues don't adhere to any agreement or SLA.
  • If you require immediate assistance, use official channels such as Salesforce Customer Support.

Summary

• This is happening from 3rd January.
• For my authorized org for a given project, the command sf project deploy start is pending for a very long time.
• It shows Status: Pending | ████████████████████████████████████████ | 0/0 Components

Steps To Reproduce

• Authorize an org for a project.
• Run sf project deploy start

Expected result

• The command should deploy everything in the org and exit with success.

Actual result

• The command goes in pending state and doesn't deploy anything.

System Information

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.22.7",
  "nodeVersion": "node-v20.10.0",
  "osVersion": "Darwin 23.2.0",
  "rootPath": "/Users/thakurtanmayrajsingh/.local/share/sf/client/2.22.7-453215f",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.3 (core)",
    "@oclif/plugin-commands 3.0.7 (core)",
    "@oclif/plugin-help 6.0.8 (core)",
    "@oclif/plugin-not-found 3.0.5 (core)",
    "@oclif/plugin-plugins 4.1.10 (core)",
    "@oclif/plugin-search 1.0.8 (core)",
    "@oclif/plugin-update 4.1.5 (core)",
    "@oclif/plugin-version 2.0.9 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.6 (core)",
    "@oclif/plugin-which 3.0.12 (core)",
    "@salesforce/cli 2.22.7 (core)",
    "apex 3.0.9 (core)",
    "auth 3.0.12 (core)",
    "data 3.0.6 (core)",
    "deploy-retrieve 2.2.6 (core)",
    "functions 1.22.11 (user)",
    "info 3.0.8 (core)",
    "limits 3.0.6 (core)",
    "marketplace 1.0.11 (core)",
    "org 3.1.2 (core)",
    "packaging 1.27.10 (core)",
    "schema 3.0.8 (core)",
    "settings 2.0.9 (core)",
    "sobject 1.0.6 (core)",
    "source 3.0.3 (core)",
    "telemetry 3.1.6 (core)",
    "templates 56.0.4 (core)",
    "trust 3.2.0 (core)",
    "user 3.1.1 (core)",
    "@salesforce/sfdx-plugin-lwc-test 1.1.1 (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.

[cristiand391]

@tanmayythakur can you share the org instance where this happens? We got another issue about this and some internal reports, seems like an Metadata API issue.

[tayfunesmer]

I and my teammates are suffering from the same problem and we're unable to deploy or retrieve changes no matter what. We're using scratch orgs and mine is USA28S instance.

[rrosset91]

My instance USA224S has the same issue

[cristiand391]

Thanks all, I'm still waiting for an answer about this.

[ajeffersonfh]

I am also having the same problem. USA224S

[cleilson-oliveira-osf]

Me as well, when I'm trying to retrieve anything from the org (a Partner Developer Edition org, instance NA233).

[1ktribble]

This is also occurring for our team and we all have MacOS devices. This command uses the old sfdx force:source:deploy command instead of the new sf project deploy start command. When I tried using sf project deploy start instead, I received a different error about Unexpected child metadata ... found for parent type [CustomObject] for custom metadata records.

Our timeout is set to 10 minutes, and at times, deploying a single class surpasses that timeout limit. Prior to v59.0 of the SOAP API, deployments were near-instantaneous.

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.21.8",
  "nodeVersion": "node-v18.16.0",
  "osVersion": "Darwin 22.6.0",
  "rootPath": "/usr/local/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.2 (core)",
    "@oclif/plugin-commands 3.0.7 (core)",
    "@oclif/plugin-help 6.0.7 (core)",
    "@oclif/plugin-not-found 3.0.4 (core)",
    "@oclif/plugin-plugins 4.1.9 (core)",
    "@oclif/plugin-search 1.0.8 (core)",
    "@oclif/plugin-update 4.1.4 (core)",
    "@oclif/plugin-version 2.0.8 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.5 (core)",
    "@oclif/plugin-which 3.0.11 (core)",
    "@salesforce/cli 2.21.8 (core)",
    "apex 3.0.8 (core)",
    "auth 3.0.10 (core)",
    "data 3.0.5 (core)",
    "deploy-retrieve 2.2.3 (core)",
    "info 3.0.7 (core)",
    "limits 3.0.5 (core)",
    "marketplace 1.0.10 (core)",
    "org 3.1.1 (core)",
    "packaging 1.26.4 (user)",
    "schema 3.0.8 (core)",
    "settings 2.0.9 (core)",
    "sobject 1.0.5 (core)",
    "source 3.0.3 (core)",
    "telemetry 3.1.4 (core)",
    "templates 56.0.4 (core)",
    "trust 3.1.2 (core)",
    "user 3.1.0 (core)",
    "sfdx-git-delta 5.31.1 (user)",
    "sfpowerkit 6.1.0 (user)",
    "texei-sfdx-plugin 2.1.3 (user)"
  ]
}

[semroig]

Same problem since yesterday here... Deploying to sandbox using Extension for Visual Studio Code and sf command (new cli) 😭

[cristiand391]

current incident:
https://status.salesforce.com/incidents/12159

just list a few NA instances, opening a case might help getting attention.

[1ktribble]

My guess is that this is related.

I'm curious if anyone has come across any workarounds as this gets fixed.

[rrosset91]

After a long time running a retrieve I have this:

20:43:32.758 Starting SFDX: Retrieve Source from Org
Cannot read properties of undefined (reading 'type')

[cristiand391]

Support is aware of this and already implementing fixes on affected instances.

20:43:32.758 Starting SFDX: Retrieve Source from Org
Cannot read properties of undefined (reading 'type')

This is a server-side issue so neither CLI or vscode extension will work, you might get different errors until it gets fixed.

[cristiand391]

this should be resolved by now.