Failure deploying a new object that is not part of my project subscription

[Margaret Martin]

Deployment of a new object that is not part of my project subscription fails with “Error: Not in package.xml”.

Steps to reproduce:

1. Within an existing project, create a new Test_Object__c.object file. When prompted, decline to add it to the metadata subscription
2. I’ll attach a sample test object, but I believe all that is required is that the object have 1 custom field.
3. Save the file, and when prompted, choose to deploy despite it being outside the metadata subscription.
4. Result is: Error:\(1, 1\) Not in package.xml
5. The log from this deployment is attached.
6. FWIW, I noticed that the package.xml being used only contained the CustomObject stanza, and the error message in the log is pointing to the custom field, so as a test I tried copying the object definition and the package.xml to a work directory and tried a deployment using sfdx. I got a similar error, though slightly more explicit that the problem is with the custom field. I added a wildcard custom field stanza, and the sfdx deployment succeeded.

‌

[Scott Wells]

Quick update...the issue here appears to be a quirk of the deployment API when deploying a new CustomObject using a package.xml that specifies a package name via the fullName element. Evidently if you only include the CustomObject type and don't say anything about the child metadata types--or at least the CustomField type...I haven't tested more than that--it fails with an error about the fields not being in the package.xml file. More research needed to get this one right. Given that the same behavior occurs via the Salesforce CLI, I'll file a bug with Salesforce. I'm not sure it makes sense to implement a workaround for this until I hear more from them.

[Scott Wells]

Issue tracker grooming.