The org resume sandbox command started taking five minutes to complete

[kyle-blair]

Summary

The sf org resume sandbox command has started taking 5 minutes and 2-30 seconds to return a response. We are managing a pool of sandboxes, and it happens for every sandbox in the pool (16 calls in a row). We are running the same workflow for a different production org, and the command returns in the typical 2-5 seconds for the sandboxes from that org. There are other similar, but not identical, scenarios within the same org where the resume call returns in seconds, as expected.

Steps To Reproduce

1. Create/refresh a sandbox from production.
2. Wait until the sandbox is complete.
3. Run the following command:

sf org resume sandbox --name sandbox --target-org production --wait 0 --json

Where "production" is an alias for an auth to the production org for the same user that initiated the sandbox create/refresh.

Expected result

• Given the --wait 0 flag, the sf org resume sandbox command should return within a reasonable amount of time, in the realm of seconds, not minutes.
• Given the --wait 0 flag, it should return reasonably quickly regardless of the actual status of the sandbox being resumed.

Actual result

The cli consistently takes 5 minutes to return, plus a couple of seconds. It's almost like there's a 5 minute timer where nothing happens, then the command starts and returns in the next couple seconds. Other usage of the resume command returns normally and does not take 5 minutes. I have not been able to discern any differences in how they're being called versus how they're behaving.

Additional Information

This is a continuation of https://github.com/forcedotcom/cli/issues/3407. That was auto-closed and I'm not able to reopen it.

System Information

Running from automation, so limited output is available. @salesforce/cli/2.107.6 linux-x64 node-v20.19.5

[github-actions[bot]]

Hello @kyle-blair :wave: It looks like you didn't include the full Salesforce CLI version information in your issue. Please provide the output of version --verbose --json for the CLI you're using (sf or sfdx).

A few more things to check:

• Make sure you've provided detailed steps to reproduce your issue.
  • A repository that clearly demonstrates the bug is ideal.
• Make sure you've installed the latest version of Salesforce CLI. (docs)
  • Better yet, try the rc or nightly versions. (docs)
• Try running the doctor command to diagnose common issues.
• Search GitHub for existing related issues.

Thank you!

[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.

[github-actions[bot]]

This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted.

[EstebanRomero84]

Hi @kyle-blair I was not able to repro this issue. Can you run the command adding the --dev-debug flag and setting env var SFORCE_LOG_LEVEL=DEBUG and share the logs?

[kyle-blair]

So, this is happening in a github action context, and is hard to reproduce outside of that. I don't have a reasonable way to add the dev debug flag to the workflow, but I did try to run with the environment environment variables that are set when --dev-debug is used (based on this discussion). That results in the sf command process exiting with 1 early on. There isn't any indication of why that happens in the output.

I will keep looking into this and trying to get more valuable output/information. It does, however, look like it has stopped happening. In a workflow run from today, connecting to each sandbox in a pool of 40 sandboxes took only 90 seconds, whereas before it would take hours.

[kyle-blair]

I think the biggest clue to finding the root cause was that the command always took five minutes plus 0-30 seconds to complete. Never less than five minutes. It was like it ran something that wasn't going to resolve, and that had a 5 minute timeout. After the 5 minutes, the command would process normally in the next 5-20 seconds. Only occurred on certain production orgs, not others. My guess is there's a network component at play.

[github-actions[bot]]

This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted.

[kyle-blair]

Commenting to keep this issue open. I'm annoyed I have to do this. I understand that certain measures must be taken to ensure the number of issues doesn't get out of control, but it's also useful to document the existence of an issue that is not resolved.

[github-actions[bot]]

This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted.