6

My app has some custom fields on an object which is a part of a packaged app (so this is a namespaced-object, in the namespace bt_stripe).

When trying to push the code with SFDX into scratch org, I've getting the following error:

$ sfdx force:source:push -u cpq-scr-1

force-app/main/default/objects/bt_stripe__Transaction__c.object-meta.xml                                               

Must specify a non-empty label for the CustomObject

The object definition XML-s doesn't have label definition, as they are defined already in the package.

For example, force-app/main/default/objects/bt_stripe__Transaction__c.object-meta.xml:

<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata"/>

Apparently, SFDX doesn't recognise that these objects definitions are special and wants to deploy them as they would be 'normal'. Any ideas how to deploy such an object definition?

Improve this question
3
  • 1
    What do you get back if you manually add the field to the managed custom object in the scratch org and then do a force:pull? Does it produce a slightly different bt_stripe__Transaction__c.object-meta.xml
    – Daniel Ballinger
    Oct 4, 2017 at 19:12
  • @DanielBallinger the objects are already there (as the bt_stripe package is installed in the scratch org), but there is nothing to pull, as the non-packaged package can't be created (pushed) :(
    – Peter Tempfli
    Oct 6, 2017 at 5:54
  • I'm having this issue :(
    – Tyler Zika
    Feb 28, 2018 at 0:24

5 Answers 5

Reset to default
7

This is a known bug and a fix is currently being worked on. The bug is in the source:convert process.

Improve this answer
5
  • 1
    as a workaround, you can just delete the <NAMESPACED-OBJECT>.object-meta.xml files; also remove these references from .sfdx/orgs/ORGNAME/sourcePathInfos.json
    – Peter Tempfli
    Jan 24, 2018 at 6:20
  • @Dave Carroll do you have a link to the SF known issue of this?
    – Seyitbek
    Oct 28, 2019 at 21:26
  • 1
    @Seyitbek To clarify, it is not a known issue, rather a bug. Known issues are have a slightly different connotation. I will attempt to find the bug since this is now 1.7 years old.
    – Dave Carroll
    Oct 29, 2019 at 23:03
  • @Seyitbek According to our bug tracking system, this fixed in the v41.18.3 release. Is your CLI up to date?
    – Dave Carroll
    Oct 29, 2019 at 23:10
  • This bug still exist, neither force:source:push nor fource:mdapi:deploy works if we have custom field added to a Custom Setting that is packaged in a managed package. For custom objects, this works fine as stated, no <NAMESPACED-OBJECT>.object-meta.xml files generated for them. I found it still being generated by Convert/Deploy (which I believe uses in background a convert & push in itself) commands for Custom Settings.
    – VarunC
    Jan 18, 2021 at 21:51
3

I encountered the same issue and 'resolved' this by removing the "object-meta.xml" file. Seems like a DX bug to me.

Improve this answer
3
  • yeeeees, but the problem is that this packaged object has additional fields in my non-packaged app -- so I need that file :(
    – Peter Tempfli
    Nov 30, 2017 at 6:33
  • When you converted the code to DX format, any non-packaged fields, should be represented as individual files in the fields directory. You should then be able to push these into the scratch org, and also pull any changes you make in the scratch org. I would recommend you start over by creating a new scratch org, install the package, then push in your code (which should have those "object-meta.xml" files removed).
    – Tommy Hogan
    Nov 30, 2017 at 16:57
  • This one works, and we are in 2020!
    – Mert Akcakaya
    Apr 20, 2020 at 16:17
1

We have the same issue after using "sfdx force:source:convert -r source-code/ -d mdapioutput/" - in the mdapioutput folder, all the objects become pretty much empty except the header and trailer. We have a work around - after covert, copy the original objects to mdapioutput to override those pretty much empty newly converted files, then deploy. It works.

Improve this answer
0

As it turned out, for packaged objects you need to delete the <NAMESPACED-OBJECT>.object-meta.xml from the object directory -- than it deploys nicely.

Improve this answer
0

I had the same symtomps but I had to correct a uppercase letter in the name of my object folder and in the name of my metadata for the object.

(Be careful because my VSC, gitlab wasn't updating my correction.)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .