The "retrieve source from org" button inline with "Custom Objects" in the OrgBrowser unfortunately only downloads "Custom" __c Objects despite showing both standard and custom when expanded. See image of bugged button.

[peternoges]

Summary

Recap: The "retrieve source from org" button (boxed in purple in the image provided below) appears broken in that it only downloads Custom Objects (c) and mdt, but for some reason no standard objects. Im claiming the bug as the button being broken in that it seems to not cascade its retrieve function downwards. More info below.

Research so far: (#1571) was delivered in the past, and although i can SEE standard objects when i expand "Custom Objects" in the OrgBrowser, the boxed/purple button from the image below only objects retrieves c and mdt into force-app/main/default/objects. Why does the purple boxed button not also retrieve standard objects too?

I've ruled out .forceignore being the cause because my .forceignore does NOT exclude __c. BTW does orgbrowser respect/obey/honor .forceignore?

After deleting everything in force-app/main/default, and pressing the button boxed in the image i cited above, the objects folder only contains c and mdt (as shown below), but no standard objects. Why are no standard objects being included?

In other words, here is an alternate image that summarizes the same issue; the Red colored (first line of text in the image) is probably the bug. Green color (second line of text in the following image) is working fine.

VS Code Version:

SFDX CLI Version: sfdx-cli/7.83.0 win32-x64 node-v12.16.1

OS and version: Windows 10, OS Build 18363.1256

[peternoges]

I've updated the structure of the original post, to add clarity / readability

[brpowell]

Hi @peternoges. The reason this happens is due to an inconsistency in the API. The Org Browser populates the list of CustomObjects using a describeMetadata() call to the Metadata API, which groups Standard Objects into the response. However, if you were to retrieve all of the CustomObjects using a wildcard in a manifest like so

<Package>
    <types>
        <members>*</members>
        <name>CustomObject</name>
    </types>
</Package>

You would only retrieve the c and mdt objects. The CLI under the hood is building a manifest like the one above when the org browser calls to retrieve all CustomObjects, which is why you're getting this unexpected behavior. One way to fix this would be to individually address each object under the Custom Objects list when calling the CLI command. However, we currently have a deploy/retrieve performance beta that uses a new library to perform those operations and does this exactly. If you enable that setting you can give it a try yourself. The enhancements are still a work in progress, but we plan on this being the way forward.

[peternoges]

Hi @brpowell,

I tried the beta feature that you mentioned, but still no luck. See below for details.

I enabled the beta feature, restarted vscode, and repeated my test steps (orgbrowser to retrieval of the "customobjects" parent node) only to receive a toast error "Retrieve (Beta) failed to run"

With the beta enabled i ran this next command, sfdx force:source:retrieve -m CustomObject but, like without the beta, it only retrieved c and mdt (not the hoped-for standard objects too) . What can we do?

For now, to workaround this, i will disable the beta in my settings and continue using describe calls + powershell to achieve a command that pulls both standard and custom objects together, but I am still interested in following updates regarding the beta and its relationship to this issue.

On Tue, Jan 5, 2021 at 6:30 AM Bryan Powell notifications@github.com wrote:

Hi @peternoges https://github.com/peternoges. The reason this happens is due to an inconsistency in the API. The Org Browser populates the list of CustomObjects using a describeMetadata() call to the Metadata API, which groups Standard Objects into the response. However, if you were to retrieve all of the CustomObjects using a wildcard in a manifest like so

* CustomObject

You would only retrieve the c and mdt objects. The CLI under the hood is building a manifest like the one above when the org browser calls to retrieve all CustomObjects, which is why you're getting this unexpected behavior. One way to fix this would be to individually address each object under the Custom Objects list when calling the CLI command. However, we currently have a deploy/retrieve performance beta https://developer.salesforce.com/tools/vscode/en/user-guide/perf-enhancements that uses a new library to perform those operations and does this exactly. If you enable that setting you can give it a try yourself. The enhancements are still a work in progress, but we plan on this being the way forward.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/forcedotcom/salesforcedx-vscode/issues/2824#issuecomment-754670053, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YXQSUJZIJZPTULXGC5O3SYMPCBANCNFSM4VBZXL4Q .

[brpowell]

Hmm would you mind sharing the error you get in the output pane when the retrieve beta failure notification pops up?

[peternoges]

Thanks @brpowell

To answer your question about the claim i made see the "output panel" below:

Recap of The claim i made: " I enabled the beta feature, restarted vscode, and repeated my test steps (orgbrowser to retrieval of the "customobjects" parent node) only to receive a toast error "Retrieve (Beta) failed to run"

"

"output panel" the output panel doesnt show much when "salesforcedx-vscode-core>Experimental: Deploy Retrieve" is ON and im retrieving the CustomObject root from OrgBrowser. Output panel shows me just two lines:

• 10:36:57.200 Finished Retrieve (Beta)
• 10:37:10.841 Starting Retrieve (Beta)

Here is a 2minute repro .mp4 of the same: https://gust.box.com/s/xdd80h692c3q2f8tix1i4k7t6dlnwmgd

[brpowell]

Appreciate the helpful video @peternoges. I haven't had any luck reproducing it on my end yet, but I'm going to mark this as a bug to address in the beta.

[git2gus[bot]]

This issue has been linked to a new work item: W-8656516

[RitamAgrawal]

@peternoges With v53.8.1 this issue has been resolved. As by clicking on Retrieve Source from Org button on the right side of Custom Objects in Org Browser, standard as well as custom objects is retrieved. Retrieved files can be accessed in force-app/main/default/objects folder.