'sf project deploy quick' is not waiting for the quick deployment to complete and returns the result of the original validation

[gdman]

Summary

Running sf project deploy quick to quick deploy a recent validation doesn't wait for the quick deployment to finish before returning (even with the --wait parameter). The deploy result it returns is the result of the original validation, NOT the quick deploy deployment. Presumably that indicates the code is waiting for the initial validation to complete (which has already completed long ago), hence the command completing prematurely.

I've tested the original sfdx force:mdapi:deploy and the behaviour there is as expected, it waits for the quick deploy and returns the quick deploy result.

Steps To Reproduce

1. Run a validation of some metadata - ideally do a large number of components so that the quick deploy takes longer and you can easily spot the issue (I reproduced using all the standard objects and some apex classes)
2. Run sf project deploy quick --api-version 58.0 --target-org [ALIAS] --job-id [VALIDATION ID] --wait 100 --json (you don't need the --json but it's helpful to see the deploy result to see the bug there)

You can run sfdx force:mdapi:deploy --apiversion 58.0 --targetusername [ALIAS] --wait -1 --validateddeployrequestid [VALIDATION ID] --json to see the expected behaviour.

P.S. Thanks for changing --validateddeployrequestid to --job-id - much nicer.

Expected result

Command waits for quick deploy to complete and returns the result of the quick deploy

Actual result

Command doesn't wait for quick deploy to complete and returns the result of the original validation instead

System Information

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.14.6",
  "nodeVersion": "node-v18.15.0",
  "osVersion": "Darwin 22.6.0",
  "rootPath": "/Users/andrew.goodman/.local/share/sf/client/2.14.6-1f2724e",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.10 (core)",
    "@oclif/plugin-commands 3.0.3 (core)",
    "@oclif/plugin-help 6.0.3 (core)",
    "@oclif/plugin-not-found 3.0.2 (core)",
    "@oclif/plugin-plugins 3.9.2 (core)",
    "@oclif/plugin-search 1.0.3 (core)",
    "@oclif/plugin-update 4.1.2 (core)",
    "@oclif/plugin-version 2.0.3 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.1 (core)",
    "@oclif/plugin-which 3.0.5 (core)",
    "@salesforce/cli 2.14.6 (core)",
    "apex 2.3.20 (core)",
    "auth 2.8.22 (core)",
    "data 2.5.19 (core)",
    "deploy-retrieve 1.19.2 (core)",
    "info 2.6.49 (core)",
    "limits 2.3.39 (core)",
    "login 1.2.37 (core)",
    "marketplace 0.3.0 (core)",
    "org 2.11.4 (core)",
    "schema 2.3.30 (core)",
    "settings 1.4.35 (core)",
    "sobject 0.2.13 (core)",
    "source 2.10.43 (core)",
    "telemetry 2.3.6 (core)",
    "templates 55.5.14 (core)",
    "trust 2.6.20 (core)",
    "user 2.3.37 (core)",
    "sfdx-git-delta 5.27.0 (user)"
  ]
}

(Updated to latest version)

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

[github-actions]

Hello @gdman 👋 None of the versions of sf you shared match the latest release.

Shared: 2.12.9
Latest: 2.14.6

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

[gdman]

Upgraded to latest version and confirmed issue still exists. Not checking rc or nightly as I think its highly unlikely this will magically have fixed itself.

[git2gus]

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

[mcarvin8]

@gdman - Agreed it should be fixed in a new CLI release. I'm currently running @salesforce/cli@2.10.2, which fixed the bug regarding the Quick Deploy ID being incorrect.

I do not have this issue with 2.10.2, so I'd recommend downgrading to this version if possible until the CLI team fixes this in a newer release.