Deploying project throws source tracking error even though the deployment was successful

[Slgrande]

Summary

When using sf project deploy start -d {some directory} -g -c -o {alias} to deploy only a specified directory to an org, the deployment is successful and still throws: Error (MetadataTransferError): Metadata API request failed: This org does not have source tracking.

Steps To Reproduce

Run sf project deploy start -d {some directory} -g -c -o {alias} and wait for the error to be displayed.

Expected result

Deployment is reported as successful if it was.

Actual result

Error (MetadataTransferError): Metadata API request failed: This org does not have source tracking and it says tests fail even though they did not.

Additional information

System Information

Using bash

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.73.9",
  "nodeVersion": "node-v20.12.2",
  "osVersion": "Darwin 23.5.0",
  "rootPath": "/Users/slgrande/.nvm/versions/node/v20.12.2/lib/node_modules/@salesforce/cli",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.17 (core)",
    "@oclif/plugin-commands 4.1.16 (core)",
    "@oclif/plugin-help 6.2.21 (core)",
    "@oclif/plugin-not-found 3.2.35 (core)",
    "@oclif/plugin-plugins 5.4.25 (core)",
    "@oclif/plugin-search 1.2.18 (core)",
    "@oclif/plugin-update 4.6.23 (core)",
    "@oclif/plugin-version 2.2.20 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.30 (core)",
    "@oclif/plugin-which 3.2.25 (core)",
    "@salesforce/cli 2.73.9 (core)",
    "apex 3.6.8 (core)",
    "api 1.3.3 (core)",
    "auth 3.6.87 (core)",
    "community 3.3.7 (user) published 46 days ago (Sat Dec 14 2024) (latest is 3.3.8)",
    "data 4.0.1 (core)",
    "deploy-retrieve 3.17.7 (core)",
    "info 3.4.32 (core)",
    "limits 3.3.44 (core)",
    "marketplace 1.3.7 (core)",
    "org 5.2.23 (core)",
    "packaging 2.9.12 (core)",
    "schema 3.3.46 (core)",
    "settings 2.4.10 (core)",
    "sobject 1.4.49 (core)",
    "telemetry 3.6.29 (core)",
    "templates 56.3.35 (core)",
    "trust 3.7.55 (core)",
    "user 3.6.6 (core)",
    "sfdmu 4.38.0 (user) published 31 days ago (Sun Dec 29 2024)"
  ]
}

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

[WillieRuemmele]

Hi @Slgrande - can you try running sf org disable tracking -o and then running the command again?

this will disable source tracking operations from the CLI, you can also disable this when creating the org with the --no-track-source flag too

[Slgrande]

Hi @WillieRuemmele,

I don't want to disable source tracking though. I would still like to use it. But my understanding is that if I specify the --source-dir, --manifest or --metadata flags then source tracking is not used and only the specified metadata is deployed. So an error should not be displayed, especially since the deployment does actually work.

[WillieRuemmele]

fair enough 😄

the only place that error is thrown is when the org is marked as 'non-sourcetracked'

the isSourceTracked method, here looks pretty straight forward.

a few more questions,

is this happening every time?

can you try

sf org disable tracking
and then
sf org enable tracking

hopefully those will reset the tracking information for the org

[Slgrande]

I was able to run sf org disable tracking
but running sf org enable tracking
gave me this error:
Error (TrackingNotAvailableError): You can't enable source tracking on this org because the SourceMember Tooling API object isn't available, or you don't have access to it.
even though source tracking is enabled in my production org.

Running disable tracking has fixed the problem.

But I'm still confused why it's mentioning source tracking at all since by specifying --source-dir, --manifest or --metadata it should not be using source tracking.

[WillieRuemmele]

I agree that it shouldn't be using it, because you specified the flags

what happens if you try to query the SourceMember object directly?

sf data query -q "SELECT MemberName FROM SourceMember" -t?