Result object for postretrieve and postsourceupdate plugin hooks doesn't support different metadata types with the same API name

[gdman]

Summary

The result object for postretrieve and postsourceupdate plugin hooks doesn't support different metadata types with the same API name. For example, a class called Account and the standard Account object will both have an aggregateName of Account and therefore only a single entry in the result. This will happen in numerous scenarios.

I'd suggest either making the aggregateName unique by including the metadata type (e.g. ApexClass:Account, CustomObject:Account) or returning an array instead of an object.

Steps To Reproduce:

Repository to reproduce:

1. Create an Apex class with name Account
2. Retrieve metadata for Account class and Account object (sfdx force:source:retrieve -m ApexClass:Account,CustomObject:Account)

Expected result

There should be an entry in the hook result for both pieces of metadata.

Actual result

There is only one entry in the hook result for either the class or the object.

Additional information

SFDX CLI Version(to find the version of the CLI engine run sfdx --version):
sfdx-cli/7.78.1-5a65d9dd2f darwin-x64 node-v12.18.3

SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core)
@oclif/plugin-autocomplete 0.1.5 (core)
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.2.0 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-plugins 1.9.1 (core)
@oclif/plugin-update 1.3.10 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-trust 3.4.3 (core)
alias 1.1.2 (core)
analytics 1.12.1 (core)
auth 1.3.0 (core)
config 1.1.10 (core)
generator 1.1.3 (core)
plugin-metadata-hook-demo 48.8.0 (link) xxx
salesforcedx 50.3.1 (core)
├─ apex 0.1.2 (core)
├─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core)
├─ custom-metadata 1.0.10 (core)
├─ salesforce-alm 50.3.1 (core)
└─ templates 50.1.0 (core)
sfdx-cli 7.78.1 (core)

OS and version:
Mac OSX 10.15.6

[github-actions]

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.

[WillieRuemmele]

Hi @gdman sorry for the delayed response, Is this still happening?

[gdman]

@WillieRuemmele thanks for getting back to me.

I've re-tested, the behaviour is better than before but IMO is still kind of odd.

Post retrieve and post source update have both metadata types (in this example an Account object and Account class) - that's better than before. However, it's odd that they are grouped together. As someone implementing a plugin, I wouldn't expect to find them grouped together just because they happen to share the same name.

The data structure looks something like:

Account: {
  workspaceElements / mdapiFilePath: [
    { Account Object, Fields, etc },
    { Account Class and Metafile }
  ]
}

Which kind of makes sense for the object with fields, links, etc i.e. the subtypes but doesn't make sense for classes (since those workspace elements are not related).

I guess it really depends what aggregateName is supposed to represent. I think of it as an API name and then the properties of that API name i.e. the component and files that relate to it e.g.

• Account (as a CustomObject) has mdapiFilePath: [ .../objects/Account.object]
• Account (as an ApexClass) has mdapiFilePath: [ .../classes/Account.cls, .../classes/Account.cls-meta.xml ]

The problem is that API names of metadata are not unique across types so for that to work, you'd need something like:

{
  ApexClass: { Account : { mdapiFilePath: [ .../classes/Account.cls, .../classes/Account.cls-meta.xml ] } },
  CustomObject: { Account: { mdapiFilePath: [ .../objects/Account.object ] } }
}

or

{
  ApexClass:Account : { mdapiFilePath: [ .../classes/Account.cls, .../classes/Account.cls-meta.xml ] },
  CustomObject:Account : { mdapiFilePath: [ .../objects/Account.object ] }
}

Either of the above data structures would probably be useful to a plugin developer - you can see the API names and how that relates to files.

With the current implementation aggregateName doesn't tell you anything, it's an arbitrary grouping of things based on having the same name. The first thing you'd have to do in every plugin is loop over it and pull out all of the workspaceElements / mdapiFilePath entries into a flat array for it to be of any use and there will be no way of knowing which files link to which piece of metadata.

On a related point, at the moment the only property of the aggregateName (in this case Account) is workspaceElements / mdapiFilePath - it won't be possible to add additional properties in the future because the children won't have common values e.g. adding a property of metadataType won't work because the children have values of ApexClass and CustomObject.

Example screenshot:

[mdonnalley]

Closing this due to inactivity. Feel free to re-open if you are still experiencing this issue.