Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-59656

executors widget makes it easy to interrupt the wrong build

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • None
    • found in Jenkins 2.176.3,
      reproduced in Jenkins 2.198
    • 2.209

      In Jenkins classical UI, users can interrupt builds using the stop button (little red cross) attached to each busy executor. Clicking this button displays a confirmation dialog (with the full display name of the build about to be interrupted, which is good). Then, on confirmation, a stop request is POSTed to the executor URL, which is something like this:
      /jenkins/computer/SOME_NAME/executors/NUMBER/stop
      or that:
      /jenkins/computer/(master)/oneOffExecutors/NUMBER/stop
      (and I guess it's not the only options, but you get the idea: the target is an executor, not a specific running task)

      Between the initial click on the cancel button and the stop request actually reaching the server, many things can happen (especially if the user hesitated on the confirmation dialog). The target executor identified by its name+number can now be executing something completely different from the build that the user was intending to interrupt.

      This is not a theoretical issue: I've came across this yesterday while doing the post-mortem analysis of an unintentionally interrupted deployment Pipeline

      I will submit a WIP PR with a proposed change to avoid this issue...

          [JENKINS-59656] executors widget makes it easy to interrupt the wrong build

          Steps to reproduce when running with only the Jenkins war (as in jenkins-dev:run):

          • create a test freestyle job with a "sleep 10" shell step
          • go back to Jenkins main page, and launch the job twice; default job config will make it run one build at a time
          • as soon as build #1 appears running in the executors view, click the stop button; you get the dialog to confirm interruption of build #1
          • count to 10 slowly, and click OK
          • check that build #1 is in success, and it's build #2 which got interrupted

          That's basically how I've tested my proposed changes so far...

          Thomas de Grenier de Latour added a comment - Steps to reproduce when running with only the Jenkins war (as in jenkins-dev:run): create a test freestyle job with a "sleep 10" shell step go back to Jenkins main page, and launch the job twice; default job config will make it run one build at a time as soon as build #1 appears running in the executors view, click the stop button; you get the dialog to confirm interruption of build #1 count to 10 slowly, and click OK check that build #1 is in success, and it's build #2 which got interrupted That's basically how I've tested my proposed changes so far...

          I will submit a WIP PR with a proposed change to avoid this issue...

          The PR is not WIP anymore, just needs more review.

          Thomas de Grenier de Latour added a comment - I will submit a WIP PR with a proposed change to avoid this issue... The PR is not WIP anymore, just needs more review.

          Fixed via PR #4264, should be released in 2.209.

          Thomas de Grenier de Latour added a comment - Fixed via PR #4264 , should be released in 2.209.

          Fixed some time ago, closing.

          Thomas de Grenier de Latour added a comment - Fixed some time ago, closing.

            tom_gl Thomas de Grenier de Latour
            tom_gl Thomas de Grenier de Latour
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: