forcedotcom
Salesforce deployment using sf command in Github workflow fails with error message : The user aborted a request.
Summary IMP This is an intermittent issue I have a Github Workflow that deploys a branch in Github to Salesforce and during deployment it fails with error message "The user aborted a request."
Steps To Reproduce
I am using below steps this workflow:
-
name: Install Salesforce CLI run: | mkdir -p ~/sf wget https://developer.salesforce.com/media/salesforce-cli/sf/channels/stable/sf-linux-x64.tar.xz tar xJf sf-linux-x64.tar.xz -C ~/sf --strip-components 1 echo "$HOME/sf/bin" >> $GITHUB_PATH ~/sf/bin/sf --version
- name: Authenticate to Salesforce DevelopDev Sandbox run: | echo "${{ secrets.SERVER_KEY }}" > server.key sf org login jwt \ --username ${{ secrets.DEPLOYMENT_USERNAME }} \ --jwt-key-file server.key \ --client-id ${{ secrets.CONSUMER_KEY }} \ --instance-url ${{ vars.INSTANCE_URL }} \ --set-default \ --alias DevSandbox - name: Deploy and run Apex tests (verbose, wait up to 5 hours for job to finish) run: | sf project deploy start \ --source-dir force-app \ --target-org DevSandbox \ --test-level RunLocalTests \ --ignore-conflicts \ --ignore-warnings \ --wait 300 \ --verbose
Expected result
The deployment should initiate by deploying develop branch to salesforce sandbox.
Actual result
Authentication is successful but it takes 22 minutes to authenticate against a sandbox and then the deployment never gets initiated in Salesforce and the deployment fails with error message "The user aborted a request." This issue is intermittent and does not happen all the times.
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] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hello @padambsharmasfdc :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
rcornightlyversions. (docs)
- Better yet, try the
- Try running the
doctorcommand to diagnose common issues. - Search GitHub for existing related issues.
Thank you!
I am using latest version of salesforce CLI { "architecture": "linux-x64", "cliVersion": "@salesforce/cli/2.103.7", "nodeVersion": "node-v22.18.0", "osVersion": "Linux 6.11.0-1018-azure", "rootPath": "/home/runner/sf", "shell": "bash", "pluginVersions": [ "@oclif/plugin-autocomplete 3.2.34 (core)", "@oclif/plugin-commands 4.1.32 (core)", "@oclif/plugin-help 6.2.32 (core)", "@oclif/plugin-not-found 3.2.65 (core)", "@oclif/plugin-plugins 5.4.46 (core)", "@oclif/plugin-search 1.2.28 (core)", "@oclif/plugin-update 4.7.4 (core)", "@oclif/plugin-version 2.2.32 (core)", "@oclif/plugin-warn-if-update-available 3.1.46 (core)", "@oclif/plugin-which 3.2.39 (core)", "@salesforce/cli 2.103.7 (core)", "agent 1.24.4 (core)", "apex 3.6.19 (core)", "api 1.3.3 (core)", "auth 3.9.0 (core)", "data 4.0.53 (core)", "deploy-retrieve 3.22.41 (core)", "info 3.4.81 (core)", "limits 3.3.64 (core)", "marketplace 1.3.8 (core)", "org 5.9.23 (core)", "packaging 2.19.5 (core)", "schema 3.3.78 (core)", "settings 2.4.42 (core)", "sobject 1.4.68 (core)", "telemetry 3.6.55 (core)", "templates 56.3.60 (core)", "trust 3.7.113 (core)", "user 3.6.34 (core)" ] }
Hi @padambsharmasfdc, can you set the env HTTP_TIMEOUT to 600000 value in the workflow step and see it that work or would it throws another error?
@soridalac , thank you sop much for your prompt response, Is this what the recommendation is ?
` jobs: deploy: runs-on: ubuntu-latest env: HTTP_TIMEOUT: 120000 # 120 seconds = 2 minutes HTTP timeout (default is 20s)
steps: - name: Checkout source code uses: actions/checkout@v4 with: ref: develop
- name: Install SFDC SLI
run: |
mkdir -p ~/sf
wget https://developer.salesforce.com/media/salesforce-cli/sf/channels/stable/sf-linux-x64.tar.xz
tar xJf sf-linux-x64.tar.xz -C ~/sf --strip-components 1
echo "$HOME/sf/bin" >> $GITHUB_PATH
~/sf/bin/sf --version
- name: 🔐 Deploy to TE Test Sandbox (No Tests)
run: |
echo "${{ secrets.SERVER_KEY }}" > server.key
sf org login jwt \
--username "${{ secrets.USERNAME }}" \
--jwt-key-file server.key \
--client-id "${{ secrets.CONSUMER_KEY }}" \
--instance-url "${{ vars.INSTANCE_URL }}" \
--set-default \
--alias testSandbox
echo "📦 Starting deployment with No Test Run..."
sf project deploy start \
--source-dir force-app \
--test-level NoTestRun \
--ignore-conflicts \
--target-org testSandbox \
--wait 300 \
--verbose`
Just letting you know that this issue is also happening in our environment. It is intermittent but quite impactful, approximately half of deployments fail.
$ sf project deploy start --target-org [email protected] -m (... redacted ...) --ignore-warnings --ignore-conflicts --wait 240
› Warning: @salesforce/cli update available from 2.103.7 to 2.104.6.
───── Deploying Metadata ─────
Stages:
1. Preparing
2. Waiting for the org to respond
3. Deploying Metadata
4. Running Tests
5. Updating Source Tracking
6. Done
▶ Preparing…
Deploying v63.0 metadata to [email protected] using the v64.0 SOAP API.
Deploy ID: 0AfKJ000006rd2E0AQ
Target Org: [email protected]
✔ Preparing (260ms)
▶ Waiting for the org to respond…
✔ Waiting for the org to respond (2.53s)
▶ Deploying Metadata…
Components: 0/2639 (0%)
Components: 63/2639 (2%)
(... redacted ...)
Components: 2612/2639 (99%)
Components: 2616/2639 (99%)
Components: 2616/2639 (99%)
✘ Deploying Metadata (1h 24m)
Deploying v63.0 metadata to [email protected] using the v64.0 SOAP API.
Status: In Progress
Deploy ID: 0AfKJ000006rd2E0AQ
Target Org: [email protected]
Elapsed time: 1h 24m
Error (MetadataTransferError): Metadata API request failed: The user aborted a request.
Updated files not restored
It started about a month ago. It mostly affects scratch org deployments.
We raised Salesforce Case #471166132. Unfortunately, Salesforce Support does not see any issues, and we weren't able to prove this is a Salesforce problem. The case was closed. Theoretically, network issues can occur anywhere along the network path. However, our runners perform multiple network operations successfully and only fail on Salesforce deployments with that. Therefore, I believe this issue is likely related to Salesforce.
We can provide any further insights since it is quite replicable here.
We are using latest CLI continuously updated.
@pawel-id , have you tried HTTP_TIMEOUT ? I am not sure what step this needs to be added
Following @soridalac’s advice, I set HTTP_TIMEOUT to 600000. Unfortunately, I’m still seeing the issue: “The user aborted a request.”
Regarding @padambsharmasfdc’s question “Where should this be added?”: this is an environment variable, which can be set in several ways. If you’re using GitHub Actions, this guide should be helpful. It might look something like this:
- name: 🔐 Deploy to TE Test Sandbox (No Tests)
run: |
echo "${{ secrets.SERVER_KEY }}" > server.key
sf org login jwt \
--username "${{ secrets.USERNAME }}" \
--jwt-key-file server.key \
--client-id "${{ secrets.CONSUMER_KEY }}" \
--instance-url "${{ vars.INSTANCE_URL }}" \
--set-default \
--alias testSandbox
echo "📦 Starting deployment with No Test Run..."
sf project deploy start \
--source-dir force-app \
--test-level NoTestRun \
--ignore-conflicts \
--target-org testSandbox \
--wait 300 \
--verbose`
env:
HTTP_TIMEOUT: 600000
Hi @pawel-id & @padambsharmasfdc, the issue came from the jsforce lib due to timeout. @pawel-id can you increase HTTP_TIMEOUT to 15 minutes and see if it will throw the same error? Thank you I'm working on increase the time out and improve error message here: https://github.com/jsforce/jsforce/pull/1760 related issue: https://github.com/forcedotcom/cli/issues/3354
I have set HTTP_TIMEOUT=900000 (15 minutes). I will monitor our pipelines and post the results here.
@soridalac @cristiand391 Please allow me to point out a few aspects. This issue started to occur about a month ago, probably due to some changes in Salesforce's infrastructure. Based on my observations, the root cause is slowdowns and timeouts on the Salesforce backend, which then manifest on the client side.
This causes issues with salesforce/cli, resulting in "The user aborted a request" errors. You are trying to resolve this by extending the timeouts. However, salesforce/cli is not the only way to interact with the Salesforce API. There are multiple other tools. For example, the "Vlocity Build Tool" (now officially part of Salesforce) also fails. Unfortunately, this tool is poorly written and practically unmaintained. It just fails without a meaningful error message, or with no message at all. We only have a correlation that the issue started happening around the same time as the "The user aborted a request" errors. This is just one example; other tools are also experiencing similar issues.
Therefore, extending the timeout in jsforce seems like a good workaround, but not a true solution. We need to address the root cause. I raised Salesforce Case #471166132, but it was dismissed because they did not see any issues on the Salesforce side. However, it seems there are ongoing problems. I understand that another team is responsible for this, but perhaps you can help or advise on how to address the root cause?
I have set HTTP_TIMEOUT=900000 (15 minutes). I will monitor our pipelines and post the results here.
Despite extending the timeout parameter to 15 minutes, the issue persists. Please find attached a screenshot and log file for further analysis.
@pawel-id
for more context, we added a default timeout for requests in jsforce here: https://github.com/jsforce/jsforce/pull/1738
that change landed in sf CLI around mid August.
Before that PR, jsforce just didn't have a timeout and would wait infinitely so it could be that the APIs always worked like that (which is also bad). We had to make the change because if the server just hangs indefinitely, the CLI stays frozen until you kill the process.
I'll try to look more into it next week if the API teams are aware of the long running issues, we'll increase it to 30min in the next sf nightly build but you can also try it with the HTTP_TIMEOUT env var.
We are seeing the same problem, exactly as @pawel-id and @padambsharmasfdc have described.
Same here - issue started to occur about 1 month ago, setting longer timeouts doesnt help. Affects DX significanlty as it breaks long running workflows without real reason returned and in random moments. We are enterprise customer 1000+ seats with unlimited license.....
I’ve been contributing reports about this issue here, and it’s still happening on our runners. From the start, I wasn’t sure of the root cause, so I wrote a script to continuously deploy dummy metadata. I ran it on our runners and, for comparison, on Heroku. The results were surprising: on our runners, it failed at a rate similar to our real deployments, while on Heroku it ran flawlessly. To be fair, this suggests the issue isn’t with Salesforce; jsforce may simply be reporting the network timeout error this way.
This doesn’t mean that every such problem might be the runners, but our case looks like it is.
We run into the same issue multiple times, our current setup relies solely on the Salesforce CLI and Jenkins.
