8

Yesterday, my Travis CI builds started to fail on a scratch org creation step:

$ sfdx force:auth:jwt:grant --clientid $CONSUMERKEY --jwtkeyfile server.key --username $USERNAME --setdefaultdevhubusername -a HubOrg Successfully authorized [secure] with org ID 00D6A000001jFciUAE

$ sfdx force:org:create -v HubOrg -s -f config/project-scratch-def.json -a ciorg ERROR: Socket timeout occurred while listening for results.

At the same time I can successfully create the scratch org from my local machine using the same commands. Was there any kind of security update of Salesforce platform? Is it possible to debug this kind of issue?

UPD: it seems that the scratch org is actually created (at least it appears inside DebHub's 'Scratch Org Infos' tab) but still unavailable to the sfdx commands. If I add --json option, I can see more details though it doesn't become any clearer

{"message":"Socket timeout occurred while listening for results.","status":1,"stack":"genericTimeoutMessage: Socket timeout occurred while listening for results.\n at ALMError (/home/travis/.local/share/sfdx/client/node_modules/salesforce-alm/dist/lib/almError.js:35:19)\n at OrgCreateCommand._streamingCallback (/home/travis/.local/share/sfdx/client/node_modules/salesforce-alm/dist/lib/scratchOrgCreateCommand.js:155:31)\n at asyncStatusClient.subscribe (/home/travis/.local/share/sfdx/client/node_modules/salesforce-alm/dist/lib/scratchOrgCreateCommand.js:203:81)\n at Timeout.timeout.setTimeout (/home/travis/.local/share/sfdx/client/node_modules/salesforce-alm/dist/lib/status.js:126:17)\n at ontimeout (timers.js:475:11)\n at tryOnTimeout (timers.js:310:5)\n at Timer.listOnTimeout (timers.js:270:5)","name":"genericTimeoutMessage","warnings":[],"action":"Use command \"sfdx force:data:soql:query -q \"SELECT Status FROM ScratchOrgInfo WHERE Id='2SR6A000000GnLQWA0'\"\" to retry. You may consider increasing --wait parameter value to increase timeout."}

Executing sfdx force:org:list --all after creation attempt shows only DevHub

  • 1
    We got the same problem. – dzh Mar 8 '18 at 22:42
6

This has also been reported on the success community and we are currently looking into the issue. Some things to note:

  1. The CLI uses the streaming API (long polling) to be notified when the scratch org is created. If the CLI doesn't get that message, then it will not try to authenticate to the org even if it has been created. We are adding a "last-ditch effort" on timeout to check if the org is created and will continue to auth if it is. The CLI will still wait the default time, but at least it will connect instead of timeout, so your CI runs may take a little more time. Here is the work item for reference. W-4795607
  2. As far as I'm aware, nothing has changed on the client or server to cause the streaming message from being sent to travis. Server and client logs look good. It is possible travis has made a change that is causing issues with long polling request, or other network latency issues causing the message to be lost. Although, if it was the latter I would imaging failures would be intermittent and we would see something on travis status page.

I'm not sure how you can debug this issue yourself. You can try to add --loglevel debug and look in the ~/.sfdx/sfdx.log but I would imagine all you will see is the CLI connecting to the streaming API and never getting a message. You could also try to manually connect to the streaming endpoint using faye on your machine, then run your CI job, and see if ANY message for that org is being sent over the streaming API at all.

  • Here's the link to the related discussion on the Success Community: success.salesforce.com/_ui/core/chatter/groups/… Latest update is that the issue has auto-fixed itself, although I have not verified that – Jelle van Geuns Mar 14 '18 at 0:22
  • I cannot confirm that, builds still failing. – Philipp Frank Mar 14 '18 at 19:17
  • It has magically resolved for some people just like it magically started failing. Not sure how. The other workarounds are to use docker or osx. We are also pushing a fix tomorrow that will try to connect to the org after timeout. So you will still have an extra 6 minutes in the build but at least it won't fail. We will continue to look into it. – Amphro Mar 15 '18 at 3:33
  • It's Carla from the Travis CI Support team here. We've received several reports of this problem in the last few weeks and unfortunately we don't know yet what could be causing these issues. Both the sudden errors and the "magical fix" for some of the users don't seem to correlate to any infrastructure changes in our end. We're in touch with some folks at Salesforce and we'll keep investigating. – iriberri Mar 20 '18 at 12:01
2

As Amphro suggested in the comments of the previous answer, switching the build platform to osx fixes the problem. Our working .travis.yml setup looks as follows:

sudo: true
os:
  - osx
language: node_js
node_js:
  - "8"
before_install:
  - npm i -g sfdx-cli
script:
  - ...

Notice that you need Node 8 for sfdx-cli (6 is the default on Travis osx).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.