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.


  • 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


  • 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


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?

  • I'm seeing the same behavior, starting ca. yesterday - is this a new problem for you too, with metadata that was previously deployable?
    – David Reed
    Commented Sep 5, 2019 at 13:02
  • Yes, it was previously working and I first noticed after updating the CLI yesterday. Unfortunately I don't know what version of the CLI I previously had where this was working - I don't regularly update and it was probably over a month to 6 weeks since my previous update.
    – Phil W
    Commented Sep 5, 2019 at 13:31
  • I can reproduce on sfdx-cli/7.21.0-964f56bd1a. For me the issue is specific to namespaced scratch orgs.
    – David Reed
    Commented Sep 5, 2019 at 13:35
  • We have a namespace for our package development. Something to note is a colleague noticed that the new failure seems independent of the actual installed client-side SFDX CLI (it started failing for him without a CLI update), making it seem like some SFDX back-end problem.
    – Phil W
    Commented Sep 5, 2019 at 13:46
  • Is the following correct? The issue is the FlexiPage has an initial Picklist Value that does not have a corresponding Picklist Value generated by the datasource="apex://..." at the time the FlexiPage compiles? Commented Sep 5, 2019 at 14:00

2 Answers 2


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).


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"/>

You must log in to answer this question.

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