Datasource Exception while pushing Experience bundle to scratch org created from snapshot
Summary
We are using Org Shape, to get all licenses from production, and Org Snapshot We created a snapshot from a non-namespace scratch org which was created from org shape. From the snapshot we created a new namespace scratch org. We got all objects and data in this scratch. Now when we try to push Experience Bundle folder into this namespace scratch, created from a snapshot, we are getting error We are using Code Builder to push the code into the scratch org
Error - MEP_Portal1 data.api.DataSourceException: Could not resolve fullName to ID
Steps To Reproduce
1 - Create a Org Shape 2 - Create a non namespace scratch org, we pushed objects and fields and created some data. 3 - Create a Org Snapshot from the scratch org in Step 2 4 - Create a namespace scratch org from Snapshot 5 - Try to deploy Experience Bundle in the scratch org created in Step 4. Before pushing enable "Enable ExperienceBundle Metadata API" in Digital Experience --> Settings You will get the error "MEP_Portal1 data.api.DataSourceException: Could not resolve fullName to ID"
No one has clue what this error is about. It has been more than 1 month the case is still open with SF support and they were not even able to get anything significant from their backend logs.
Expected result
Experience bundle should get deployed
Actual result
Error - MEP_Portal1 data.api.DataSourceException: Could not resolve fullName to ID
System Information
Code Builder or VS Code
PASTE_VERSION_OUTPUT_HERE
Additional information
We are using latest version of SFDX CLI
Hello @ashutrix03 :wave: It looks like you didn't include the full Salesforce CLI version information in your issue.
Please provide the output of version --verbose --json for the CLI you're using (sf or sfdx).
A few more things to check:
- Make sure you've provided detailed steps to reproduce your issue.
- A repository that clearly demonstrates the bug is ideal.
- Make sure you've installed the latest version of Salesforce CLI. (docs)
- Better yet, try the
rcornightlyversions. (docs)
- Better yet, try the
- Try running the
doctorcommand to diagnose common issues. - Search GitHub for existing related issues.
Thank you!
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.
Hi @ashutrix03 can you append --dev-debug flag to your project deploy start command, or the command where the error is thrown? that will help us narrow down where the bug is occuring
@WillieRuemmele attaching the log file log.txt
@WillieRuemmele - Did you get a chance to check the log? Do you have any update on the issue?
@ashutrix03 - beginning to look now, can you please provide the version information requested. If you're not on latest please upgrade, try again, and report back
@WillieRuemmele Here is the output of Version command. Today also I updated to latest cli version but again same error. last week I did the same. We are using codebuilder.
{ "architecture": "linux-x64", "cliVersion": "@salesforce/cli/2.36.8", "nodeVersion": "node-v20.11.1", "osVersion": "Linux 6.1.79-99.167.amzn2023.x86_64", "rootPath": "/home/codebuilder/.local/share/sf/client/2.36.8-fa01960", "shell": "bash", "pluginVersions": [ "@oclif/plugin-autocomplete 3.0.13 (core)", "@oclif/plugin-commands 3.2.2 (core)", "@oclif/plugin-help 6.0.20 (core)", "@oclif/plugin-not-found 3.1.1 (core)", "@oclif/plugin-plugins 5.0.5 (core)", "@oclif/plugin-search 1.0.20 (core)", "@oclif/plugin-update 4.2.3 (core)", "@oclif/plugin-version 2.0.16 (core)", "@oclif/plugin-warn-if-update-available 3.0.15 (core)", "@oclif/plugin-which 3.1.7 (core)", "@salesforce/cli 2.36.8 (core)", "apex 3.1.3 (core)", "auth 3.5.1 (core)", "data 3.2.4 (core)", "deploy-retrieve 3.5.3 (core)", "info 3.1.2 (core)", "limits 3.2.1 (core)", "marketplace 1.1.0 (core)", "org 3.6.3 (core)", "packaging 2.3.0 (core)", "schema 3.2.0 (core)", "settings 2.1.2 (core)", "signups 2.1.2 (user)", "sobject 1.2.1 (core)", "source 3.2.2 (core)", "telemetry 3.1.17 (core)", "templates 56.1.0 (core)", "trust 3.5.1 (core)", "user 3.4.3 (core)", "sfdmu 4.33.5 (user)" ] }
@ashutrix03 - this will take me a while to get the required orgs, metadata, etc. Can you try something for me? In step 4, create a scratch org from the snapshot, but without a namespace. I have a hunch that the ExperienceBundle in your local project requires namespace information that it doesn't have, and thus why the org can't resolve the "fullName to ID"
@WillieRuemmele I did try creating a scratch org without namespace and I was able to deploy the community folder. The problem is unfortunately our code has namespace references in the source code hence creating a scratch org with namespace is needed.
One more thing we removed any dependency on namespace from experience bundle folder
After reading quite a bit about the ExperienceBundle type, and how it inherits fullName from the default Metadata type, I think that the namespace needs to be prefixed to the EB's fullName in the package.xml
If you want, you could verify this.
- run the deploy with SF_MDAPI_TEMP_DIR=deb, this should fail, but create a metadata-format directory that we'd modify
- in the new
deb/package.xmlfile change thefullNameof the EB to be prefixed with your namespace as mentioned in the references above - run
sf project deploy start --metadata-dir debwhich will deploy the metadata-format directory
After following the steps that you mentioned now I am getting these errors
Component Failures [4]
| Type Name Problem Line:Column
| ─────── ────────────────── ───────────────────────────────────────────────────────────── ───────────
| Error Default_MEP Portal Audience needs at least one criteria.
| Error MEP Portal In field: PicassoSite - no SiteDotCom named MEP_Portal1 found
| Error MEP_Portal In field: Name - no Network named MEP Portal found
In the package.xml I added namespace to the EB fullname
This issue has been linked to a new work item: W-15481620
hey @ashutrix03
I was looking at a similar GH issue around namespaces and found a workaround that might work here as well
https://github.com/forcedotcom/cli/issues/1803#issuecomment-2064398820
@WillieRuemmele - Any update on the Work Item [W-15481620]??(https://gus.lightning.force.com/lightning/r/ADM_Work__c/a07EE00001oMsuDYAS/view)
Hey @ashutrix03 - did you look at using string replacements? https://github.com/forcedotcom/cli/issues/1803#issuecomment-2064398820
@WillieRuemmele Is this issue fixed? Just now saw you marked it as completed.
@ashutrix03 - I closed it due to inactivity, have you seen my previous comments/suggestions?
@WillieRuemmele I did. We are going to try it this week and get back to you with the observation. Do you have any update on the work order raised?
Oh that sounds great - it was in waiting for 1 month, I was waiting on you to try out my suggestion. We'll absolutely reopen this issue based on your findings. If the string replacement doesn't work for you, this will involve a considerable amount of engineering effort to essentially mimic the string replacement functionality. I believe the string replacement will work, it might just have a complex/lengthy setup to get everything replaced correctly