18

I'm building a DX project now, and every time I try to push some fields, force:source:push fails to recognize that the fields are an addition. I've tried deleting the source files, pushing, and then adding it back, editing properties in it, as well as creating a new artifact folder, putting the files in there, pushing, then moving it back to where I want it. Each time, the net result is that my scratch org ends up without the field in play, yet I can't get the field to push. Is there some file I can modify, or command argument, that will allow me to force this field to be pushed correctly? Even better, is there a way to force a recalculation of the artifacts so that I can get everything back in sync, since I don't even know what's missing from my org at this point? I have approximately 24,000 files to go through, so manual checking is a futile effort at best.


Additional Info

When this bug occurs, force:source:status does not show that the file is created or modified, even after modifying the attributes of the field or moving it to a new file path then moving it back.

Editing .sfdx/orgs/<username>/sourcePathInfos.json to modify the file attributes or remove the entry completely have no effect on resolving this bug.

I have had some luck deleting the contents of .sfdx/orgs/, but then I typically end up with lots of errors about duplicate relationship names and lots of other errors.

What's really odd about it is that sometimes, I can add another file, since I'm spoonfeeding DX about 10-20 files at a time between each push, and the previously bugged out fields will show that they were added, but logging in to the scratch org, they still don't exist. At that point, they won't push again.

Ultimately, this question is to try and find the most foolproof, easiest way to resync the file system with the scratch org.


Demo Repo that demonstrates the problem. Readme includes instructions, but basically involves doing something like this:

$ git clone https://https://github.com/brianmfear/demo-repo.git
$ cd demo-repo
$ sfdx force:org:create -f config/project-scratch-def.json -a demo-repo -v DevHub
$ sfdx force:source:push

At this point, you'll see the following output:

STATE  FULL NAME                 TYPE         PROJECT PATH
─────  ────────────────────────  ───────────  ─────────────────────────────────────────────────────────────────────────────
Add    Account.Invalid_Field__c  CustomField  force-app\main\default\objects\Account\fields\Invalid_Field__c.field-meta.xml
Add    Account.Valid_Field__c    CustomField  force-app\main\default\objects\Account\fields\Valid_Field__c.field-meta.xml


=== Push Errors
PROJECT PATH                                                                   ERROR
─────────────────────────────────────────────────────────────────────────────  ─────────────────────────────────────────────────────────────
force-app\main\default\objects\Account\fields\Invalid_Field__c.field-meta.xml  Field Missing_Field__c does not exist. Check spelling. (3:13)

So, to fix it, let's say we delete Invalid_Field__c:

$ rm force-app/main/default/Account/fields/Invalid_Field__c.field-meta.xml

Then try to push again:

$ sfdx force:source:push -u demo-repo

=== Pushed Source
STATE    FULL NAME                 TYPE         PROJECT PATH
───────  ────────────────────────  ───────────  ─────────────────────────────────────────────────────────────────────────────
Deleted  Account.Invalid_Field__c  CustomField  force-app\main\default\objects\Account\fields\Invalid_Field__c.field-meta.xml

Note that the invalid field was deleted (but erroneously not marked as a local deletion, because it doesn't exist on the server), and the other remaining field doesn't exist.

Now, you need to clear the cache to fix it...

$ rm -r .sfdx/orgs/*
$ sfdx force:source:push -u demo-repo

=== Pushed Source
STATE  FULL NAME               TYPE         PROJECT PATH
─────  ──────────────────────  ───────────  ───────────────────────────────────────────────────────────────────────────
Add    Account.Valid_Field__c  CustomField  force-app\main\default\objects\Account\fields\Valid_Field__c.field-meta.xml
  • Though I haven't come across this scenario and was able to push any file changed locally (which should be the expected behavior in your scenario as well), the documentation mentions At this point, we start change-tracking locally on the file system and remotely in the scratch org to determine which metadata has changed. Not sure if it could be the volume of the files (24K). Are you able to get the difference between local and scratch using the status (force:source:status)? – Jayant Das Apr 20 '18 at 16:49
  • 1
    That's really interesting. And if it does not show any changed status, then most likely that's why it does not ever pushes any changes to the scratch org. Have you tried with just a few files, say 5-10 to start with, just to get an idea if volume is something that is causing this issue here? Worth circling it with Salesforce support. Thoughts? – Jayant Das Apr 20 '18 at 16:55
  • I don't think it's a volume issue. We're dealing with this same issue this morning with reports and dashboards and we only have ~100 components in this package. Our issue might be slightly different because the folders had been in the .forceignore file, but after removing them from this file they are still not being pushed up and changes are not being reflected. (It's worth noting this was working yesterday just fine.) – Robert Watson Apr 20 '18 at 17:27
  • 1
    @JayantDas Yeah, it seems broken. I'm just trying to get a more manageable push strategy for every time this thing goes sideways, which seems to be several times a day. – sfdcfox Apr 20 '18 at 18:18
  • 1
    I am unable to reproduce this. If this is still happening, please let me know. As for the ONE FILE dammit! we are working on new commands to allow that. – Dave Carroll May 3 '18 at 19:41
1

I will investigate this further. While not citing this as the cause, I would suggest making sure your permsets reflect what ever new source you push.

  • 2
    I can confirm that this is a bug. @sfdxfox, thanks for the easily reproducible demo. Will be filing a bug for this issue. – Dave Carroll May 3 '18 at 21:00
  • Now that SFDX is a thing, I find my fingers often typing "sfdx" when I meant to type "sfdc" too ;-) – Robert Watson May 3 '18 at 23:24
  • 1
    @RobertWatson I'm halfway tempted to change my moniker to sfdxfox, lol. – sfdcfox May 4 '18 at 3:22
  • I need a like button – Dave Carroll May 4 '18 at 21:46
  • 2
    @RobertWatson - The best place to "watch" is the weekly release notes for the CLI. developer.salesforce.com/media/salesforce-cli/releasenotes.html It looks like this will be fixed in the next week or so. – Dave Carroll May 23 '18 at 19:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.