sf org resume scratch returns timeout error after v2.78.3 when using org shape

[lennartstevensnl]

Summary

I'm using the sf project create scratch command with the --async parameter to create a scratch org based on an org shape. The command returns a jobId which I use to call the sf org resume scratch command to periodically check for the creation status. Recently, shortly after version 2.78.3 the sf org resume scratch command stopped working.

Steps To Reproduce

{
  "orgName": "MyOrgName",
  "sourceOrg": "00DXXXXXXXXXXXX",
  "language": "en_US",
  "features": [
    "PersonAccounts",
    "AdditionalFieldHistory:40"
  ],
  "settings": {
    "caseSettings": {
      "systemUserEmail": "some.email@email.com"
    }
  }
}

• Create a project-scratch-def.json as above and ensure there is a valid sourceOrg (org shape from the DevHub).

• In the cli execute the following command: sf org create scratch -f "config/project-scratch-def.json" -y "30" -a "newScratchOrg" --async --json

• The result looks simalar to:

{
  "status": 0,
  "result": {
    "username": "test-123456789012@example.com",
    "scratchOrgInfo": {
      "attributes": {
        "type": "ScratchOrgInfo",
        "url": "/services/data/v64.0/sobjects/ScratchOrgInfo/2SR120000000123WAU"
      },
      "Id": "2SR230000000123WAU",
      "OwnerId": "0050J0000012345QAC",
      "IsDeleted": false,
      "Name": "00003448",
      "CreatedDate": "2025-06-18T14:35:35.000+0000",
      "CreatedById": "0050J0000012345QAC",
      "LastModifiedDate": "2025-06-18T14:35:37.000+0000",
      "LastModifiedById": "005200000012345AAC",
      "SystemModstamp": "2025-06-18T14:35:37.000+0000",
      "LastViewedDate": "2025-06-18T14:35:35.000+0000",
      "LastReferencedDate": "2025-06-18T14:35:35.000+0000",
      "Edition": null,
      "Username": null,
      "AdminEmail": null,
      "OrgName": "MyOrgName",
      "DurationDays": 30,
      "ConnectedAppConsumerKey": "PlatformCLI",
      "ConnectedAppCallbackUrl": "http://localhost:1717/OauthRedirect",
      "Namespace": null,
      "Features": "PersonAccounts;AdditionalFieldHistory:40;API",
      "Snapshot": null,
      "Country": null,
      "Language": "en_US",
      "Package2AncestorIds": null,
      "SourceOrg": "00DXXXXXXXXXXXXXXX",
      "HasSampleData": false,
      "Release": "Current",
      "SignupUsername": "test-123456789012@example.com",
      "Status": "Creating",
      "ErrorCode": null,
      "ScratchOrg": "00DAP0000012345",
      "SignupInstance": "FRA12S",
      "AuthCode": null,
      "SignupCountry": "NL",
      "SignupEmail": "some.email@email.com",
      "SignupTrialDays": 30,
      "LoginUrl": null,
      "Description": null,
      "ExpirationDate": "2025-07-18",
      "LastLoginDate": null,
      "DeletedBy": null,
      "DeletedDate": null
    },
    "warnings": []
  },
  "warnings": [
    "Record types defined in the scratch org definition file will stop being capitalized by default in a future release.\nSet the `org-capitalize-record-types` config var to `true` to enforce capitalization."
  ]
}

• Use the value of Id, for the resume command. sf org resume scratch --job-id 2SR230000000123WAU --json

Expected result

• Normally the command would have returned the creation status and additional values as a result of the creation.

Actual result

• The command responds within ms with a timeout error.

{
  "name": "ScratchOrgResumeTimeOutError",
  "message": "The client has timed out.",
  "exitCode": 1,
  "context": "OrgResumeScratch",
  "stack": "ScratchOrgResumeTimeOutError: The client has timed out.\n    at SfCommandError.from (file:///C:/Software/nvm/v22.14.0/node_modules/@salesforce/cli/node_modules/@salesforce/sf-plugins-core/lib/SfCommandError.js:39:16)\n    at OrgResumeScratch.catch (file:///C:/Software/nvm/v22.14.0/node_modules/@salesforce/cli/node_modules/@salesforce/sf-plugins-core/lib/sfCommand.js:323:47)\n    at OrgResumeScratch._run (C:\\Software\\nvm\\v22.14.0\\node_modules\\@salesforce\\cli\\node_modules\\@oclif\\core\\lib\\command.js:185:29)\n    at async Config.runCommand (C:\\Software\\nvm\\v22.14.0\\node_modules\\@salesforce\\cli\\node_modules\\@oclif\\core\\lib\\config\\config.js:456:25)\n    at async run (C:\\Software\\nvm\\v22.14.0\\node_modules\\@salesforce\\cli\\node_modules\\@oclif\\core\\lib\\main.js:96:16)\n    at async file:///C:/Software/nvm/v22.14.0/node_modules/@salesforce/cli/bin/run.js:15:1",     
  "cause": "undefined",
  "warnings": [],
  "code": "ScratchOrgResumeTimeOutError",
  "status": 1,
  "commandName": "OrgResumeScratch"
}

Additional information

• The issue doesn't happen in sf cli version 2.78.3 or earlier.
• The issue happens with later versions such as the current latest version.

Print screen or sf org resume scratch command without --json
https://ibb.co/nXXPNjk

System Information

{
  "architecture": "win32-x64",
  "cliVersion": "@salesforce/cli/2.92.7",
  "nodeVersion": "node-v22.14.0",
  "osVersion": "Windows_NT 10.0.19045",
  "rootPath": "C:\\Software\\nvm\\v22.14.0\\node_modules\\@salesforce\\cli",
  "shell": "powershell",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.29 (core)",
    "@oclif/plugin-commands 4.1.25 (core)",
    "@oclif/plugin-help 6.2.28 (core)",
    "@oclif/plugin-not-found 3.2.55 (core)",
    "@oclif/plugin-plugins 5.4.39 (core)",
    "@oclif/plugin-search 1.2.24 (core)",
    "@oclif/plugin-update 4.6.42 (core)",
    "@oclif/plugin-version 2.2.28 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.40 (core)",
    "@oclif/plugin-which 3.2.35 (core)",
    "@salesforce/cli 2.92.7 (core)",
    "agent 1.22.8 (core)",
    "apex 3.6.19 (core)",
    "api 1.3.3 (core)",
    "auth 3.6.126 (core)",
    "data 4.0.37 (core)",
    "deploy-retrieve 3.22.19 (core)",
    "info 3.4.65 (core)",
    "limits 3.3.56 (core)",
    "marketplace 1.3.8 (core)",
    "org 5.7.13 (core)",
    "packaging 2.14.0 (core)",
    "schema 3.3.65 (core)",
    "settings 2.4.29 (core)",
    "signups 2.6.28 (user) published 31 days ago (Sun May 18 2025) (latest is 2.6.32)",
    "sobject 1.4.59 (core)",
    "telemetry 3.6.43 (core)",
    "templates 56.3.49 (core)",
    "trust 3.7.97 (core)",
    "user 3.6.25 (core)",
    "sfdx-browserforce-plugin 4.8.2 (user) published 8 days ago (Mon Jun 09 2025)",
    "sfdx-git-delta 6.13.1 (user) published 11 days ago (Fri Jun 06 2025)"
  ]
}

[github-actions]

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.

[EstebanRomero84]

Hi @lennartstevensnl thank you for reporting this issue.
In version 2.84.6 we added a --wait flag to the sf org resume scratch command (release note).

Since you are not passing a value for the wait flag, the cli uses the default value of 0. This means the polling client doesn't wait and throws the timeout error immediately. If you pass a value in the wait flag you will see the output showing the elapsed time.

So from my interpretation this is working as expected. Thoughts?

[lennartstevensnl]

Hi @EstebanRomero84,

Thank you for your feedback. I appreciate your time.

I'm running another test as per your suggestion on the following version: @salesforce/cli/2.93.7 win32-x64 node-v22.16.0.

Command used to create the scratch org using org shape:

sf org create scratch -f "config/project-scratch-def.json" -y "30" -a "newScratchOrg" --async --json

Command used for polling the status (With your suggestion to have a --wait other than the default)

sf org resume scratch -i "2SRbS0000000EPZWA2" --wait 1 --json

After one minute the reponse timed out with exit code 1.

{
  "name": "ScratchOrgResumeTimeOutError",
  "message": "The client has timed out.",
  "exitCode": 1,
  "context": "OrgResumeScratch",
  "stack": "ScratchOrgResumeTimeOutError: The client has timed out.
    at SfCommandError.from (file:///C:/Users/lennart/AppData/Local/sf/client/2.93.7-e4d4398/node_modules/@salesforce/sf-plugins-core/lib/SfCommandError.js:39:16)
    at OrgResumeScratch.catch (file:///C:/Users/lennart/AppData/Local/sf/client/2.93.7-e4d4398/node_modules/@salesforce/sf-plugins-core/lib/sfCommand.js:323:47)
    at OrgResumeScratch._run (C:\Users\lennart\AppData\Local\sf\client\2.93.7-e4d4398\node_modules\@oclif\core\lib\command.js:185:29)
    at async Config.runCommand (C:\Users\lennart\AppData\Local\sf\client\2.93.7-e4d4398\node_modules\@oclif\core\lib\config\config.js:456:25)
    at async run (C:\Users\lennart\AppData\Local\sf\client\2.93.7-e4d4398\node_modules\@oclif\core\lib\main.js:96:16)
    at async file:///C:/Users/lennart/AppData/Local/sf/client/2.93.7-e4d4398/bin/run.js:15:1",
  "cause": "undefined",
  "warnings": [],
  "code": "ScratchOrgResumeTimeOutError",
  "status": 1,
  "commandName": "OrgResumeScratch"
}
        The client has timed out.

Expected:

• I would expect that the response would contain the status Creating. As in v2.78.3 for example.

---

After typing all the above I decided to run again the sf org resume scratch -i "2SRbS0000000EPZWA2" --wait 1 --json command. The result is now a valid response with status Active.

It looks like it took around 5 minutes to complete.

 "CreatedDate": "2025-06-24T18:39:51.000+0000",
 "LastModifiedDate": "2025-06-24T18:44:25.000+0000",

Still I think it doesn't make sense that even with --wait 1 the resume command returns a time out, which isn't the case with previous cli versions. Let me know what you think?

[EstebanRomero84]

@lennartstevensnl this is a common behavior in commands that use a --wait flag, if user sets a value, the cli will keep polling the status of the operation till it completes or the wait time run out, whatever happens first. If the operation completes, the command returns the status, if not, it throws the Timeout error.

I agree that it is a change in how the command worked in previous versions, so I thinks a possible improvement could be that if the wait time is not used then return the current status of the operation. How does it sound?

[lennartstevensnl]

I like that suggestion. That would make perfect sense! Whatever the status may be, e.g. Creating. But it would also make sense to return the current status after the wait time runs out right?

[EstebanRomero84]

Yes, I think we can do that. I'll create a bug to track the work.

[git2gus]

This issue has been linked to a new work item: W-18895095

[jshackell-sfdc]

This issue is fixed in 2.100.3 (Aug 6, 2025).