SFDX CLI initial deployment failure: chicken and egg?

Question

Using the latest sfdx CLI version (sfdx-cli/7.22.0-de5c6ecff8 win32-x64 node-v10.15.3) I am now facing a problem with initial deployment (force:source:push) to a scratch org.

Scenario:

• We have an LWC component that has a string-based target config property with a datasource supported by an Apex class:

  <property name="definitionName" label="Definition Name" type="String" required="true" datasource="apex://ScheduleDefinitionPickList"/>

• This Apex class queries all instances of one of our custom metadata types and provides their developer names as the picklist entries (but isValid always returns true - we previously saw an issue around validation checks in deployment)

• We include flexipages in our source base that include the LWC and reference these custom metadata type instances

Outcome:

• Every single flexipage with the LWC embedded within it fails to deploy, with a reported error of:

  Component [namespace:name] attribute [definitionName]: Invalid datasource. Encountered runtime exception in Apex class: [namespace.ScheduleDefinitionPickList]

• The whole deployment is failed

• No log messages from the Apex code are included in the Async Metadata operations that get logged during deployment

One of these log files does show how the code does get used, for example:

 09:47:23.94 (94535542)|VARIABLE_SCOPE_BEGIN|[2]|this|VisualEditor.DesignTimePageContext|true|false
 09:47:23.94 (94611883)|VARIABLE_ASSIGNMENT|[2]|this|{}|0x965d848
 09:47:23.95 (95994788)|CODE_UNIT_STARTED|[EXTERNAL]|namespace\.ScheduleDefinitionPickList
 09:47:23.95 (96102907)|CODE_UNIT_FINISHED|namespace\.ScheduleDefinitionPickList

Workaround:

Removing the datasource definition from the LWC's meta data file property specification allows the deployment to succeed. Adding it back in and incrementally deploying that change also succeeds.

This looks like a chicken and egg problem given that the deployment includes the apex code, the custom metadata type instances and the flexipages (though to be honest, since we only return true from validation the custom metadata type instances should be irrelevant).

Has anyone else seen this? If you have, do you know if this also messes up installation of a package containing the same components?

Is there a solution that allows us to retain this datasource?

Answer 1

This problem may be a side-effect of a fix to a Known Issue that rolled out over the last week or so (or may be unrelated and coincidentally originating with something in the same patch).

Either way, we have side-stepped this problem by introducing Aura components that are thin wrappers for our LWC components that use a datasource, and then using these wrappers in the flexipages instead of the LWCs. We were forced to do this because of a separate problem, discussed here.

Note that we have not had to include our namespace prefix in the datasource specification in the Aura wrappers in this workaround (though it may be that adding the namespace prefix could fix this issue directly - an exercise for the reader).

Answer 2

A workaround for this issue is to append the correct namespace in the datasource.

So your property element name would look like :-

<property name="definitionName" label="Definition Name" type="String" required="true" datasource="apex://[componentNamespace].ScheduleDefinitionPickList"/>