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

Improve this question
1
  • 1
    We got the same problem.
    – dzh
    Commented Mar 8, 2018 at 22:42

2 Answers 2

Reset to default
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.

Improve this answer
4
  • 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
    Commented Mar 14, 2018 at 0:22
  • I cannot confirm that, builds still failing.
    – Philipp Frank
    Commented Mar 14, 2018 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
    Commented Mar 15, 2018 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
    Commented Mar 20, 2018 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).

Improve this answer

You must log in to answer this question.

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