I am currently receiving a REQUEST_RUNNING_TOO_LONG error when using the Force.com Mirgration Tool and Ant with Jenkins. I've read quite a few posts about this error and understand that this is generally due to long running requests such as non-selective SOQL queries, bad practice like SOQL in for loops, and other various items that could cause tests/code to go over the CPU governor limits.

My current setup is as follows:

  1. Using Intellij IDEA Ultimate with the Illuminated Cloud Force.com Plugin to complete development work in a Developer sandbox.

  2. Pushing commits, when ready to a Git feature branch

  3. When the feature is ready, merging the appropriate commits to the QA branch

  4. Jenkins is watching the QA branch for commits and when one comes in it fires off a job to push the metadata to the QA Developer Pro sandbox

  5. The Jenkins job first connects to Git to pull the last commit which works great. It then dynamically builds the Package.xml file via a Bash script, also working great. Finally, Jenkins is calling Ant and the Force.com Migration Tool to push the metadata, which fails.


<?xml version="1.0" encoding="UTF-8"?>
<project xmlns:sf="antlib:com.salesforce" default="sf" basedir=".">
  <target name="Build">
    <echo>Continuous Integration Build</echo>
    <property file="build.QA.properties"/>
    <property environment="env" />
    <antcall target="${build.cmd}" />
  <target name="DeployAndCheckOnly">
   <echo>Deploy Code CheckOnly in Org with username: ${sf.username}</echo>
    <sf:deploy username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" deployRoot="C:\Program Files (x86)\Jenkins\jobs\QA Git Branch to QA Salesforce Org\workspace" logType="Detail" checkOnly="${sf.checkOnly}" />
  <target name="DeployAndRunAllTests">
    <echo>Deploy and RunAllTests in Org with username: ${sf.username}</echo>
    <sf:deploy username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" deployRoot="C:\Program Files (x86)\Jenkins\jobs\QA Git Branch to QA Salesforce Org\workspace" logType="Detail" runallTests="${sf.runallTests}"/>


## build.properties
sf.username = myname@mydomain.com.qa
sf.password = supersecretpassword
sf.serverurl = https://test.salesforce.com

## settings to change in branch properties
## copy the build.master.properties to build.[branch].properties
sf.runallTests = false
sf.checkOnly = true
build.cmd = DeployAndCheckOnly


<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">

Resulting messages from Jenkins:

[Slaesforce Build Files] $ cmd.exe /C '"ant.bat -file build.xml "-DC=Program Files (x86)JenkinsSlaesforce Build Filesbuild.QA.properties" Build && exit %%ERRORLEVEL%%"'
Buildfile: C:\Program Files (x86)\Jenkins\Slaesforce Build Files\build.xml

     [echo] Continuous Integration Build
     [echo] DeployAndCheckOnly

     [echo] Deploy Code CheckOnly in Org with username: myname@mydomain.com.qa
[sf:deploy] Request for a deploy submitted successfully.
[sf:deploy] Request ID for the current deploy task: 0Af29000000i0kvCAA
[sf:deploy] Waiting for server to finish processing the request...
[sf:deploy] Request Status: Pending
[sf:deploy] Request Status: InProgress
[sf:deploy] Request Status: InProgress
[sf:deploy] Request Status: Failed

C:\Program Files (x86)\Jenkins\Slaesforce Build Files\build.xml:8: The following error occurred while executing this line:
C:\Program Files (x86)\Jenkins\Slaesforce Build Files\build.xml:12: Failed to process the request successfully. Cause(UNKNOWN_EXCEPTION): REQUEST_RUNNING_TOO_LONG: Your request was running for too long, and has been stopped.

Total time: 1 minute 39 seconds
Build step 'Invoke Ant' marked build as failure
Finished: FAILURE

With a total run time of 1.5 minutes, of which only a fraction of that was "InProgress" I am not sure what could be running too long. I also do not know how I can troubleshoot this issue further. Anyone have any ideas?

  • 1
    Can you try building in another org ?Also try with less components to narrow the cause if the issue? Dec 14 '15 at 2:16
  • 1
    I'm starting to think the issue has to do with my folder structure, I have "src" as my root folder in git so when Jenkins wraps my data with the package.xml the "src" folder is not included which is required for the deployment. I'm getting my git structure setup correctly and will post back if that resolves the issue. Dec 15 '15 at 19:20

Based on the discussion in the comments...

The problem appears to be with how the package contents was being passed to Salesforce. That is, it deployed when directly passed to the Metadata API via workbench as a flat structure, but was failing when the folder structure was included in the zip file.

As per the answer to Metadata Deploy - Package.xml Failure, the deployRoot folder structure needs to be:

+ src
|-- package.xml
  +-- classes
    |-- MyCustomWrapper.cls
    |-- MyCustomWrapper.cls-meta.xml

Try updating your sf:deploy in the build.xml with attributes for:

  • pollWaitMillis="10000"

    The number of milliseconds to wait between polls for retrieve/deploy results. The default value is 10000 milliseconds (ten seconds). For long-running processes, increase this number to reduce the total number of polling requests, which count against your daily API limits.

  • maxPoll="200"

    The number of polling attempts to be performed before aborting. The default value is 200. When combined with the default value of pollWaitMillis (10000), this means the Force.com Migration Tool will give the server process a total of 2,000 seconds (33 minutes) to complete before timing out. The total time is computed as 200 poll attempts, waiting 10 seconds between each.

This will increase the timeout duration.

  • Unfortunately I am still getting the same error even with these added. Dec 14 '15 at 2:11
  • And it still fails at about one and a half minutes? What happens if you run the command outside of Jenkins? I.e. If you use ant directly how does the deploy go? Dec 14 '15 at 7:46
  • The consensus in What causes REQUEST_RUNNING_TOO_LONG test errors? doesn't really isolate a cause that would work for your scenario. As Mohith suggests, try deploying fewer components to isolate the issue. Also try explicitly excluded the tests from running. Dec 14 '15 at 8:04
  • I'll reduce the package.xml to one class and work from there to see if it works. Dec 14 '15 at 18:05
  • 1
    @techbusinessman I've updated the answer with the requirements around the deployRoot folder structure. Dec 17 '15 at 1:05

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.