Getting "Metadata API request failed: Cannot read properties of null (reading 'split')"

[steinwinde]

Summary

I'm getting this error when deploying a single Apex trigger (both with sf and via VSCode), after struggling with issue 4935 and following the advice in the latter issue to delete the .sf/orgs/[org ID] folder. The error appears despite the deployment being successful.

Steps To Reproduce

sf project deploy start --metadata ApexTrigger:Foo
Deploying v54.0 metadata to [my user] using the v59.0 SOAP API.
Deploy ID: 0Af3H00001EreEiSAJ
Status: In Progress | ... | 1/1 Components (Errors:0) | 0/0 Tests (Errors:0)
Error (1): Metadata API request failed: Cannot read properties of null (reading 'split')

The end of .sf/sf-2023-08-30.log is this:

{"level":20,"time":1693400847500,"name":"sf:MetadataApiDeploy","msg":"MDAPI status update: InProgress"}
{"level":20,"time":1693400849281,"name":"sf:MetadataApiDeploy","msg":"MDAPI status update: Succeeded"}
{"level":20,"time":1693400849283,"name":"sf:SourceTracking","msg":"received scopedPostDeploy event"}
{"level":20,"time":1693400849284,"name":"sf:SourceTracking","msg":"ensureRemoteTracking: remote tracking already exists"}
{"level":20,"time":1693400849285,"name":"sf:RemoteSourceTrackingService","msg":"Computed SourceMember polling timeout of 5s"}
{"level":20,"time":1693400849285,"name":"sf:RemoteSourceTrackingService","msg":"Polling for 0 SourceMembers from revision 38642 with timeout of 5s"}
{"level":20,"time":1693400849285,"name":"sf:RemoteSourceTrackingService","msg":"SELECT MemberType, MemberName, IsNameObsolete, RevisionCounter FROM SourceMember WHERE RevisionCounter > 38642"}
{"level":20,"time":1693400849285,"name":"sf:connection","method":"GET","url":"https://[...]/services/data/v59.0/tooling/query?q=SELECT%20MemberType%2C%20MemberName%2C%20IsNameObsolete%2C%20RevisionCounter%20FROM%20SourceMember%20WHERE%20RevisionCounter%20%3E%2038642","headers":{"content-type":"application/json","user-agent":"sfdx toolbelt:"},"msg":"request"}
{"level":30,"time":1693400850231,"name":"sf:Config","msg":"Reading config file: C:\Users\felix\.sf\config.json"}
{"level":30,"time":1693400850234,"name":"sf:Config","msg":"Reading config file: C:\Users\felix\vsc\[...]\.sf\config.json"}
{"level":20,"time":1693400850239,"name":"sf:TelemetryReporter","msg":"Testing connection to https://dc.services.visualstudio.com with timeout of 1000 ms"}
{"level":20,"time":1693400850423,"name":"sf:TelemetryReporter","msg":"Successfully made a connection to https://dc.services.visualstudio.com"}
{"level":20,"time":1693400850423,"name":"sf:AppInsights","msg":"creating appInsightsClient"}
{"level":20,"time":1693400850430,"name":"sf:AppInsights","msg":"Sending telemetry event: salesforce-cli/metadata_api_deploy_result"}
{"level":20,"time":1693400850431,"name":"sf:AppInsights","msg":"Sending telemetry exception: Metadata API request failed: Cannot read properties of null (reading 'split')"}
{"level":20,"time":1693400850432,"name":"sf:AppInsights","msg":"Sending telemetry event: salesforce-cli/COMMAND_EXECUTION"}

After deactivating telemetry the last line in the log is the one with "sf:connection". Does parsing the result from the SourceMember query fail? There was an entry for the trigger in the table, but even after deleting it (and deleting all returned entries), the error remains.

The same problem exists when deploying diverse other triggers and classes.

I've finally done
sf project reset tracking
and this resulted in "Error (1): Cannot read properties of null (reading 'split')" too. This was successful too, because I'm back where I came from now.

System Information

Same with VSCode Salesforce Extension Pack 58.13.1 (see thread here) and even after reverting to 57.10.2.

Sandbox Version: 59.0
cmd

{
  "cliVersion": "@salesforce/cli/2.5.8",
  "architecture": "win32-x64",
  "nodeVersion": "node-v18.15.0",
  "osVersion": "Windows_NT 10.0.22621",
  "shell": "cmd.exe",
  "rootPath": "C:\\Users\\felix\\AppData\\Local\\sf\\client\\2.5.8-cb030e8",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.6 (core)",
    "@oclif/plugin-commands 2.2.22 (core)",
    "@oclif/plugin-help 5.2.17 (core)",
    "@oclif/plugin-not-found 2.3.37 (core)",
    "@oclif/plugin-plugins 3.2.6 (core)",
    "@oclif/plugin-search 0.0.22 (core)",
    "@oclif/plugin-update 3.1.32 (core)",
    "@oclif/plugin-version 1.3.8 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.48 (core)",
    "@oclif/plugin-which 2.2.30 (core)",
    "@salesforce/cli 2.5.8 (core)",
    "apex 2.3.10 (core)",
    "auth 2.8.12 (core)",
    "data 2.5.6 (core)",
    "deploy-retrieve 1.17.5 (core)",
    "info 2.6.39 (core)",
    "limits 2.3.30 (core)",
    "login 1.2.26 (core)",
    "org 2.10.0 (core)",
    "schema 2.3.23 (core)",
    "settings 1.4.25 (core)",
    "sobject 0.2.4 (core)",
    "source 2.10.31 (core)",
    "telemetry 2.3.0 (core)",
    "templates 55.5.10 (core)",
    "trust 2.6.1 (core)",
    "user 2.3.28 (core)"
  ]
}

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

[oagostinho]

@steinwinde I have the same situation. Do you have any updates about this? Thanks!

[mshanemc]

@steinwinde @oagostinho
It looks like (maybe? I don't have a way to replicate it, so this is wild conjecture) the SourceMembers table might have something in it that doesn't have a name property. If so, that's a bug.

When you get to the place where you can encounter the bug, can you do a project retrieve preview and see what's changed in the org that might be causing this? Alternatively, if that doesn't show anything interesting, try

sf data query -t -q "SELECT MemberType, MemberName, IsNameObsolete, RevisionCounter FROM SourceMember"

I'm looking for something that is missing its memberType property OR doesn't have only has a Type followed by __ but nothing after that.

Also, did this start happening after the v59 (winter24) release?

[steinwinde]

@mshanemc , thanks for picking this up. I've created a new project and don't have this problem inside of the new project. There is nothing indicating a problem in the SourceMember table. I'm attaching the complete output of sf data query:
source-member.txt
There is neither anything dodgy in the output of project retrieve preview; in particular the MemberType is shown on each line and consists of a series of letters without any underscore. (Note this affects deployments of any meta data type I tried on this org from this project.)
This is a recent observation and the Sandbox recently got 59. Not sure, if this is related.
(The issue is annoying when using VSCode, because VSCode does not acknowledge the success of the deployment, but generates high CPU load and memory usage, until after ~ 10 minutes the deployment times out.)

[ImJohnMDaniel]

@mshanemc -- I, too, have been seeing this issue on and off over the summer. The only thing that seems to resolve is to scrap the scratch org and build a new one. I do not know what triggers the condition, but once it is triggered, VSCode does the deployment but still registers the error. When I follow-up by executing the cli project deploy start command from the terminal, it lists the files that VSCode just tried to deploy and shows them as "unchanged". Checking the UI's "Deployment Status" screen confirms that the VSCode deployment attempt did succeed but for some reason VSCode is not getting the correct response. Let me know if you have questions.

[steinwinde]

@mshanemc , in my setup the problem turned out to be that many of the sf project commands expect two git like files in:

[project directory]/.sf/orgs/[org ID]/localSourceTracking

These are files with the name config (can be empty) and HEAD (contains "ref: refs/heads/main"), which are apparently both required for the "local shadow repo" of the source-tracking implementation. I have not investigated, when these files should have been created; probably when sf was clever enough to re-create [project directory]/.sf/orgs/[org ID] after I deleted it (see the very beginning of my initial bug report); all I can say is that it hadn't happened in my case. Manually creating these files or copying them over from other projects fixes the issue.

[github-actions]

This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted.

[mshanemc]

Yeah, you generally don't want to mess around with deleting the tracking files. They're not meant to be manually modified--we don't test all the ways you could get those into an invalid state.

You should be able to restore the whole project's tracking by calling sf project retrieve start -d pkgDir1 (and use additional -d pkgDir2 as needed).

[steinwinde]

@mshanemc , okay, I learn from that that deleting the .sf/orgs/[org ID] directory of the project is unsupported. (Nevertheless, I will experiment with the sf project retrieve start... at the next opportunity.)

[github-actions]

This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted.