HealthCloudAddOn Scratch Org Feature Causing "DeployingSettingsTimeoutError" Issue

[jdschleicher]

Summary

When attempting to create a scratch org in a local environment or within a CI environment, if the scratch org definition file has the feature for "HealthCloudAddOn" it takes a significant amount of time. In a completely blank scratch org with just HealthCloudAddOn, the scratch org will take significant time to create or fail. With an actual Product code base and additional features alongside the HealthCloudAddOn feature, we receive the "DeployingSettingsTimeoutError" error.

Steps To Reproduce:

Repository to reproduce: dreamhouse-lwc

NOTE: If your issue is not reproducable by dreamhouse-lwc, i.e. requires specific metadata or files, we require a link to a simple Salesforce project repository with a script to setup a scratch org that reproduces your problem.

1. fork repository of dreamhouse-lwc and clone locally
2. open up local dreamhouse-lwc repository locally in VSCode or in bash terminal
3. in the config/project-scratch-def.json file add the feature "HealthCloudAddOn" to the already existing features
4. run the command "sf force org create -f config/project-scratch-def.json -a dhouse -v devhub_alias --json"

Expected result

scratch org created

Actual result

Describe what actually happened.

System Information

• Which shell/terminal are you using? (e.g. bash, zsh, powershell 5, powershell 7, cmd.exe, etc.)

  bash

• If you are using sf

  • Run sf version --verbose --json

• Paste the output here

$ sf version --verbose --json { "cliVersion": "@salesforce/cli/1.72.0", "architecture": "win32-x64", "nodeVersion": "node-v16.17.1", "osVersion": "Windows_NT 10.0.19041", "shell": "C:\Program Files\Git\usr\bin\bash.exe", "rootPath": "C:\Users\JonathonSchleicher\AppData\Roaming\npm\node_modules\@salesforce\cli", "pluginVersions": [ "@oclif/plugin-autocomplete 2.1.7 (core)", "@oclif/plugin-commands 2.2.12 (core)", "@oclif/plugin-help 5.2.8 (core)", "@oclif/plugin-not-found 2.3.22 (core)", "@oclif/plugin-plugins 2.4.3 (core)", "@oclif/plugin-search 0.0.14 (core)", "@oclif/plugin-update 3.1.9 (core)", "@oclif/plugin-version 1.3.1 (core)", "@oclif/plugin-warn-if-update-available 2.0.33 (core)", "@oclif/plugin-which 2.2.17 (core)", "@salesforce/cli 1.72.0 (core)", "apex 2.2.9 (core)", "auth 2.7.10 (core)", "data 2.3.8 (core)", "deploy-retrieve 1.8.7 (core)", "env 2.1.3 (core)", "info 2.6.3 (core)", "limits 2.3.10 (core)", "login 1.2.4 (core)", "org 2.6.3 (core)", "schema 2.3.5 (core)", "settings 1.4.2 (core)", "sobject 0.1.11 (core)", "source 2.9.1 (core)", "telemetry 2.1.3 (core)", "templates 55.4.5 (core)", "trust 2.4.5 (core)", "user 2.3.5 (core)", ] }

Additional information

[github-actions[bot]]

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.

[mshanemc]

The root problem is going to be a "not the CLI" kind of problem that you'll want to open a Salesforce case to get some additional attention.

you can --wait longer on the org create command to avoid the error, or --async and then use the resume command to pick it up later to see if it's ready.

For what it's worth, I had two of them complete within 3 minutes with HealthCloudAddOn so there's a chance it's only misbehaving on some instances during signup.

10762 2:53 sf org create scratch -f config/project-scratch-def.json -y 1 -d

[github-actions[bot]]

We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.

[jdschleicher]

thank you @mshanemc , we haven't had any challenges since the issue was recorded.

Is there any type of way to differentiate and troubleshoot case compared to cli?

We have support from some technical account managers I could collaborate with as well.

I'm not sure if you all have any documentation you can point us to in regards to isolating when a scenario where our "pod" may be down or not but any type of information can help us understand where to point our troubleshooting efforts is greatly appreciated.

[mshanemc]

this works fine these days (finishes in <60s)