-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
force:org:create - Socket timeout occurred while listening for results. #1149
Comments
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. |
We have seen this error as well, it was too slow in creating a scratch org. Looks like the CLI is not respecting the default time out of 6 mins |
Same here. It's randomly getting stuck and not respecting the |
Same here. We have a large team of developers, and a lot (but not all) are struggling with this issue. The same with GitHub Actions using scratch org's to automate tasks. |
Same here. not only with sfdx-cli/7.114.0 but also with older versions (sfdx-cli/7.82.1). There is also a known issue reported about this issue: |
Sorry for the delayed response everyone, can someone add the |
Hi, Here is a log from when I got socket timeout:
|
I also tried increasing the wait time to 15 min, but no change. The scratch org is created and you can query for it in ActiveScratchOrg long before the job times out. Seems to happen more often in GitHub Actions than from desktop (Windows/Mac), but don't know why. |
As it happens to @chfosli, this occurs more often in GitHub Actions than using the terminal. Here you have the whole debug log:
|
This is a combination of two issues
|
Same here, getting socket time out for since last 2 days. But we can see the org is created in DebHub. Is there any workaround for this issue?
|
@WillieRuemmele : Did you find anything in our logs? |
This issue has been linked to a new work item: W-9832185 |
Any updates on this? Our CI/CD system across multiple projects are running out of Active Limit, though the socket timeouts, the scratch org is created behind the scenes and we have to resort to manual deletion |
How much longer do we have to suffer? |
After updating to |
I'm still having the same issue with |
Hello, today I had contact with SF support. It seems that this problem will be solved with the winter release. |
Is there any updates on this from the forcedotcom/cli team. Please prioritize this fix as its impacting our day to day use for Scratch Orgs through our pipelines. |
I'm afraid it's been working only for a couple days, we're seeing the same problem again 😕. |
@javierCTL - I've raised a case in my production org to also create more visibility on this issue so hopefully it gets more attention. How often are your scratch orgs failing? |
On our CI this occurred every day many times. Now we cleaned up a lot of scratch since we reached our limit of active scratch and it seems it occurs less frequently. We are still monitoring this behaviour. |
Compiling data from this thread here is what I see:
The |
Salesforce Support has comeback and referred to this open known issue to have the community upvote to get more visibility. At its current state, a final fix won't be available until Summer '22 Release which for most of us on this thread seems a long time away from stability. @azlam-abdulsalam - Can you comment more to the specific question above regarding not respecting timeout and how we are handling it in our open source orchestration scripts for CI/CD. |
It's not like it never worked. It broke about a month ago, around the time when this ticket was opened. They are just continuing to treat salesforce DX community with contempt. |
@shetzel Thanks for the analysis The default time out I believe is set to 6 minutes, but in our observation, sometimes the streaming server takes atleast 15 mins to return generic timeout message and in some cases it just hanged. Overriding the -w parameter to a lower value didnt help, not sure why. the alm code looks alright. @vuha-acn In our plugin, where we are simply using a child_process to invoke the cli, we explicitly timeout after 6 mins,if we dont get any output from the cli and do an auto cleanup for all the lost orgs. |
This! There is a regression somewhere in SF, and should be fixed. |
We're suffering the same as @richsabel, most of our jobs get stuck until we manually cancel them. It worked for a day after updating to |
@azlam-abdulsalam and others - thank you for all the data points. While this is primarily a server problem and should be fixed there, I think the CLI can do some things to make this better, both near term and long term. Near term: The streaming listener approach is not reliable. Default to use the polling strategy instead. That code is already there, it's just not the default strategy. This should make it easier to respect the timeout as well. Provide an environment variable to toggle the strategy in case polling reveals other bugs. Long term: The streaming listener approach is not reliable. Remove it. Just use polling once the polling strategy is proven more reliable. |
This was fixed in latest v7.120.0, release notes: |
* fix history, merge in rough evaluation * [ch88982] polling with bridge (#3) * [ch89618] add basic CI to build bridge * Increase testing and expand on handling of error cases. (#6) * Event scaffolding, and basic operators / allFlags (#7) * [ch88983] More event logic (#8) * [ch88983] event summarization (#9) * [ch88983] Add more complete event bundling (#10) * [ch92034] more evaluation operator support (#12) * [ch92034] Add semver operator support (#13) * fix issues to pass wrapper * [ch89623] API documention (#14) * miscellaneous tiny tasks (#15) * do not require key for config * remove commented out try / catch blocks * another location where LDConfig constructor needed to be updated * Add a helper Makefile to assist dev cycle * update Makefile to force push to Salesforce * update LDClient to construct default LDConfig if config is null * [ch94250] limit event queue (#16) * Cleanup bridge implementation (#17) * [ch94716] Use new SDK domain (#19) * Remove RESTWrapper logic (#18) * [ch94746] add constructor to LDClient that uses default LDConfig (#20) * [ch94864] add user agent to bridge #21 * update semver to the format we have used before * add minimal changelog * add beta disclaimer * correct title of Salesforce in README * correct reference to incorrect SDK * update changelog initial warning * Adding the pull request template (#22) * [ch98184] [ch98185] Add JWT auth, add scratch org CI, refactor (#23) * [ch98838] bump http timeout to 30 seconds and make configurable #24 * [ch98980] releaser config for beta 2 (#25) * Removed the guides link * [ch99747] Add alias support (#26) * [ch110766] Fix bucketBy behavior when attribute does not exist * remove beta warning (#27) * [ch108417] experimentation allocation (#29) * Updates docs URLs * Guard against invalid PEM decoding of OAUTH_JWT_KEY The return value of pem.Decode must be checked, as it can be nil if decoding fails. This previously caused a panic; now it should return an error. * Clarify error messages related to private key decoding * Add gitignore * Rename master->main in PR template * Bump circleci/salesforce-sfdx to 2.2.0 * Update SFDX cli version & scratch org definition (#35) * Update SFDX cli version SFDX is failing on scratch org creation due to a socket timeout. This seems to be a widespread issue (forcedotcom/cli#1149) so this commit attempts to use a later version. * Fix scratch org settings. https://salesforce.stackexchange.com/questions/298721/failed-to-deploy-settings-to-scratch-org * Rename Event to LDEvent (#37) * Rename Event to LDEvent * Rename EventTest -> LDEventTest * Add a unit test to verify no name collision Co-authored-by: Harpo Roeder <[email protected]> Co-authored-by: Ben Woskow <[email protected]> Co-authored-by: Ben Woskow <[email protected]> Co-authored-by: LaunchDarklyCI <[email protected]> Co-authored-by: LaunchDarklyReleaseBot <[email protected]> Co-authored-by: Ember Stevens <[email protected]> Co-authored-by: ember-stevens <[email protected]> Co-authored-by: Casey Waldren <[email protected]>
Issue still presented in sfdx-cli/7.188.1 darwin-x64 node-v18.13.0 |
Summary
Running a simple force:org:create command and getting a "Socket timeout occurred while listening for results." error. Have increased the wait time to 15min and still get the same error.
Steps To Reproduce:
Repository to reproduce: dreamhouse-lwc
sfdx force:org:create -f config\project-scratch-def.json --setalias sbgcc3 --durationdays 7 --setdefaultusername --json --loglevel fatal --wait 15
config\project-scratch-def.json contents:
{
"orgName": "Demo company",
"edition": "Developer",
"features": ["EnableSetPasswordInApi"],
"settings": {
"lightningExperienceSettings": {
"enableS1DesktopEnabled": true
},
"mobileSettings": {
"enableS1EncryptedStoragePref2": false
}
}
}
Expected result
Scratch Org should be created.
Actual result
Error: Socket timeout occurred while listening for results.
System Information
Run
sfdx version --verbose --json
and paste the output here.{
"cliVersion": "sfdx-cli/7.114.0",
"architecture": "win32-x64",
"nodeVersion": "node-v14.17.5",
"pluginVersions": [
"@oclif/plugin-autocomplete 0.3.0 (core)",
"@oclif/plugin-commands 1.3.0 (core)",
"@oclif/plugin-help 3.2.2 (core)",
"@oclif/plugin-not-found 1.2.4 (core)",
"@oclif/plugin-plugins 1.10.1 (core)",
"@oclif/plugin-update 1.4.0-3 (core)",
"@oclif/plugin-warn-if-update-available 1.7.0 (core)",
"@oclif/plugin-which 1.0.3 (core)",
"@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)",
"@salesforce/sfdx-trust 3.6.0 (core)",
"alias 1.1.10 (core)",
"apex 0.2.7 (core)",
"auth 1.7.1 (core)",
"config 1.2.23 (core)",
"custom-metadata 1.0.12 (core)",
"data 0.6.0 (core)",
"generator 1.1.7 (core)",
"limits 1.2.1 (core)",
"org 1.6.9 (core)",
"salesforce-alm 52.2.5 (core)",
"schema 1.0.8 (core)",
"sfdx-cli 7.114.0 (core)",
"source 1.0.9 (core)",
"telemetry 1.2.3 (core)",
"templates 52.1.0 (core)",
"user 1.4.0 (core)"
],
"osVersion": "Windows_NT 10.0.19042"
}
Additional information
When looking in the DevHub org an new record is created in Scratch Org Info... but its incomplte (eg no OrgId)
The text was updated successfully, but these errors were encountered: