title: AWS lambda ResourceConflictException on deployment
body: <p>We have several lambda functions, and I've automated code deployment using the <a href="https://github.com/justinPihony/gradle-aws-plugin-reboot" rel="nofollow noreferrer">gradle-aws-plugin-reboot</a> plugin.</p>
  <p>It works great on <em>all but one</em> lambda functions. On that particular one, I'm getting this error:</p>
  <pre><code>com.amazonaws.services.lambda.model.ResourceConflictException: The operation cannot be performed at this time. An update is in progress for resource: arn:aws:lambda:*redacted*:the-lambda-that-fails (Service: AWSLambda; Status Code: 409; Error Code: ResourceConflictException; Request ID: 8fef505a-587c-4e77-a257-182d6eecadd0; Proxy: null)
  </code></pre>
  <p>There's an additional caveat to that  error, though: It only happens on Jenkins. Running the deployment task from my local machine works. I can <em>kind of</em> reproduce the issue locally by spamming deployments in rapid succession, in which case every second one fails. Which is understandable, considering the error message.</p>
  <p>An interesting thing about this is, though, that while it fails with the same error, it does not fail at the same point as jenkins does. When I do that locally, it fails when deploying the environment, on jenkins it <em>always</em> fails when deploying the code. I'm not sure which one the plugin does first, though.
  Also, it doesn't quite <em>always</em> fail on jenkins. There are rare instances when even the deployment of this lambda succeeds. There are no instances of any of the other ones failing, though.</p>
  <p>I am aware of the new <a href="https://docs.aws.amazon.com/lambda/latest/dg/functions-states.html" rel="nofollow noreferrer">lambda states feature</a>, and that it can potentially produce this error. However, since all the other lambdas work, which are using the same code in both build.gradle as well as the jenkinsfile, it seems rather unlikely that this would be my issue.</p>
  <p>Here's what the deployment task in gradle looks like:</p>
  <pre><code>   register&lt;jp.classmethod.aws.reboot.gradle.lambda.AWSLambdaMigrateFunctionTask&gt;(&quot;deploy&quot;) {
  
          // Create the environment variables from the gradle property configuration.
          // users and passwords should be stored in the system properties file, not the projects!
          val (environmentProperties, function) = if (branch == &quot;master&quot;) {
              val webcamServicePutterProd: String by project
              val webcamServicePutterProdPwd: String by project
              mapLambdaProperties(&quot;deployProd_&quot;, webcamServicePutterProd, webcamServicePutterProdPwd) to
                      &quot;lambda-function-name-prod&quot;
          } else {
              val webcamServicePutterDev: String by project
              val webcamServicePutterDevPwd: String by project
              mapLambdaProperties(&quot;deployDev_&quot;, webcamServicePutterDev, webcamServicePutterDevPwd) to
                      &quot;lambda-function-name-dev&quot;
          }
  
          val jarFile = File(&quot;build/libs&quot;).walk().first { it.name.endsWith(&quot;-all.jar&quot;) }
          functionName = function
          zipFile = jarFile
          handler = &quot;webcam.yellow.sqs.lambda.WebcamWorker::handleRequest&quot;
          publish = true
          environment = environmentProperties
      }
  
  </code></pre>
  <p>As mentioned, this is pretty much identical in all the lambdas, apart from properties, obviously. Properties can't really be the issue either though, since they're the same in my local environment and on jenkins.</p>
  <p>The deployment execution in the jenkinsfile is pretty unspectacular. It first uploads the jar to S3 for archival, then executes the gradle task for deploying the lambda. Just to be sure, I tried without the S3 upload just in case that might have some obscure connection, but that didn't help either.</p>
  <pre><code>        stage('Deploy artifact') {
              when {
                  equals expected: 'true', actual: deployArtifact
              }
              steps {
              // archive build on S3
                  withAWS() {
                      s3Upload(
                              workingDir: 'build/libs/',
                              includePathPattern: '*-all.jar',
                              bucket: 'yellow-artifacts',
                              path: &quot;webcam-worker-lambda/${artifactFolder}/&quot;
                      )
                  }
  
                  // deploy build to lambda
                  sh './gradlew deploy'
              }
          }
  
  </code></pre>
  <p>I've spent hours going over all the configurations of the different lambdas, comparing them, looking for differences that might be a source of the issue, but I'm pretty much out of ideas where the problem might be located by now. Anybody got any hunches?</p>