Deleted custom field doesn't show in source tracking

[mdavidsonST]

Summary

We have a sandbox with change tracking enabled and after I delete a custom field the change doesn't show in source change tracking data. Results also show Layouts being deleted when they should only be modified.

Steps To Reproduce:

Sandbox link: https://wmw--1wf.sandbox.my.salesforce.com/

1. Delete a custom field on standard or custom object.
2. run sfdx force:source:status -u 1wfSandboxOrg

Expected result

Results should include Remote Deleted custom field name

Actual result

Results include profile, record types, and layouts impacted, but not the actual custom field.

System Information

• Which shell/terminal are you using? powershell 7.2.5

• If you are using sfdx

  • Run sfdx version --verbose --json { "cliVersion": "sfdx-cli/7.158.1", "architecture": "win32-x64", "nodeVersion": "node-v16.15.1", "pluginVersions": [ "@oclif/plugin-autocomplete 0.3.0 (core)", "@oclif/plugin-commands 1.3.0 (core)", "@oclif/plugin-help 3.3.1 (core)", "@oclif/plugin-not-found 1.2.6 (core)", "@oclif/plugin-plugins 1.10.11 (core)", "@oclif/plugin-update 1.5.0 (core)", "@oclif/plugin-warn-if-update-available 1.7.3 (core)", "@oclif/plugin-which 1.0.4 (core)", "@salesforce/sfdx-plugin-lwc-test 1.0.0 (core)", "alias 2.1.0 (core)", "apex 0.13.0 (core)", "auth 2.2.2 (core)", "community 2.0.0 (core)", "config 1.4.12 (core)", "custom-metadata 2.0.0 (core)", "data 2.0.4 (core)", "generator 2.0.2 (core)", "info 2.0.1 (core)", "limits 2.0.1 (core)", "org 2.0.1 (core)", "salesforce-alm 54.6.2 (core)", "schema 2.1.1 (core)", "sfdx-cli 7.158.1 (core)", "signups 1.2.0 (core)", "source 2.0.3 (core)", "telemetry 2.0.0 (core)", "templates 55.0.0 (core)", "trust 2.0.1 (core)", "user 2.1.0 (core)" ], "osVersion": "Windows_NT 10.0.22000" }

    Additional information

[github-actions[bot]]

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.

[mshanemc]

can you run this against your sandbox

sfdx force:data:soql:query --t -q "SELECT MemberType, MemberName, IsNameObsolete, RevisionCounter FROM SourceMember WHERE RevisionCounter"

If you can see an entry in the SourceMember table, then the server is fine and there's a bug is on the CLI (and we'll get it fixed for you). IsNameObsolete should be true for the deleted field. If your sandbox has crazy number of entries in that table, you can filter by MemberType or MemberName or IsNameObsolete

If you don't see an entry, then we'll have to get the people who own custom fields to fix it and that'll take a while longer.

[mdavidsonST]

I don't see it in the list.

[mshanemc]

was it on the Standard Contact object?

[mdavidsonST]

Yes, Standard Contact object. We're using Salesforce Platform with a managed package, but the field being deleted was not from the managed package. I also tried deleting a field from a custom object with same results.

[mdavidsonST]

Is there somewhere else I should create a ticket?

[mshanemc]

yeah, normal salesforce support case. You can include a link to this issue when you give all the info about it.

[github-actions[bot]]

We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.

[mdavidsonST]

I received an update for my support ticket.

We checked the setup audit trail and we found that it is capture on their but not in SFDX. Since SFDX is handled by our developer team we will be transferring this case to our developer team so that they can assist you better.

[mdavidsonST]

Well now Salesforce support is saying that "There is no help article from salesforce confirming that this object (sourcemember) will track the deleted fields."

Can anyone confirm whether source tracking and sfdx force:source:status should track deleted fields? If so can you point me to documentation that I can share with support? What's weird is I do have one sandbox where one of the deleted fields shows up in source tracking, but the other fields I deleted don't.

[mshanemc]

What's weird is I do have one sandbox where one of the deleted fields shows up in source tracking, but the other fields I deleted don't.

That is weird.

They definitely show up in scratch orgs. I think we've seen other sandbox tracking issues where if you make the field then delete, they'd be in the tracking but it wasn't happening for fields that got created as part of the sandbox replication (that is, the field is a custom field in your prod org) and you're trying to delete it.

Sandbox tracking has always been just a bit different in unexpected ways. If your case ends up with a dead end, I can still log one but I expect it to not get much attention without something from customers.

[mdavidsonST]

I may give up on this as I don't think source tracking is there yet. Luckily all the page layout changes get captured so I can promote the pieces the users see and then go back and manually delete the fields again or figure out how to build a destructive changes file from scratch.

I've also found weird behaviors if a field is created and then renamed in the sandbox. Unless I get clarity from someone who actually knows what source tracking should and shouldn't be able to handle we'll just try to avoid edge cases.

[mshanemc]

a lot of people missed this, but there is a force:source:manifest:create that will spit out a package.xml based on either filepaths or metadata types (so it's the same as -m and -p from source:deploy)

and of course force:source:delete will delete stuff without messing with manifests.

[mdavidsonST]

I just got a call with Salesforce and they said that source tracking and sfdx do not track deletions. I've asked them to update the documentation to clarify that. I'll also be asking the devops center folks to clarify in their documentation what they mean when they say that it handles deleted metadata.

[RupertBarrow]

Hi @mshanemc, can you confirl the status of this issue and the explanations given ? Does Source Tracking track deletions, even in sandbox and even of fields (eg) created in prod then deleted in sandbox ?

[mshanemc]

duplicate of https://github.com/forcedotcom/cli/issues/1093

The underlying issue a source tracking bug on sandboxes.

[amtrack]

@mshanemc Is there an update or Known Issue for it?

I rarely work with Sandboxes and when this was reported to me I was surprised.

From what I can see, this is how Source Tracking works in Sandboxes:

• Refresh or create a Sandbox
• The SourceMember Tooling API object does not have any records (check with: sf data query -t -q "SELECT MemberType, MemberName, IsNameObsolete FROM SourceMember")
• Create new Metadata or update existing Metadata -> a SourceMember record get's created automatically ✅
• Delete existing Metadata: -> no SourceMember record get's created automatically ❌

[mshanemc]

I'll talk to them about it doing something.

My understanding is that deletions are tracked EXCEPT where they were created as part of the sbox copy (ie, the field exists in the org the sandbox was created from). There's no good reason for that to be the case.

[mshanemc]

there's a KI now. @amtrack @RupertBarrow https://issues.salesforce.com/issue/a028c00000zIbnE/source-tracking-doesnt-track-members-that-were-created-before-the-framework-being-enabled

[mshanemc]

duplicate of https://github.com/forcedotcom/cli/issues/1093