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

Queue item cancellation via REST api works but returns a 404

    Details

    • Similar Issues:

      Description

      When I call http://<Jenkins_URL>/queue/cancelItem?id=<queueItem> it does cancel the item but it returns a 404. It must return a 200 instead.

        Attachments

          Issue Links

            Activity

            barthelemy Barthélémy von Haller created issue -
            barthelemy Barthélémy von Haller made changes -
            Field Original Value New Value
            Link This issue is related to JENKINS-16333 [ JENKINS-16333 ]
            Hide
            barthelemy Barthélémy von Haller added a comment -

            Probably related to JENKINS-16333

            Show
            barthelemy Barthélémy von Haller added a comment - Probably related to JENKINS-16333
            Hide
            danielbeck Daniel Beck added a comment -

            Is this still an issue in recent Jenkins versions? The Queue.doCancelItem code looks reasonable.

            Where is /queue/cancelItem documented as being part of the REST API?

            Show
            danielbeck Daniel Beck added a comment - Is this still an issue in recent Jenkins versions? The Queue.doCancelItem code looks reasonable. Where is /queue/cancelItem documented as being part of the REST API?
            Hide
            jglick Jesse Glick added a comment -

            Is this reproducible? doCancelItem unconditionally returns a redirect response. It should never be a 404, even if the queue item does not exist.

            Show
            jglick Jesse Glick added a comment - Is this reproducible? doCancelItem unconditionally returns a redirect response. It should never be a 404, even if the queue item does not exist.
            jglick Jesse Glick made changes -
            Labels queue rest
            Component/s core [ 15593 ]
            Component/s http_request [ 17539 ]
            Hide
            barthelemy Barthélémy von Haller added a comment -

            I have just tried again and could reproduce it with Jenkins 1.579.

            I did https://xxx.yyy.ch/jenkins/view/job/<jobname>/buildWithParameters?module=xyz
            And got a 201 with a location in the header : Location: https://xxx.yyy.ch/jenkins/queue/item/1137/

            I then I did : https://xxx.yyy.ch/jenkins/queue/cancelItem?id=1137
            And got the following header :
            Status Code: 404 Not Found
            Cache-Control: no-cache
            Connection: close
            Content-Length: 952
            Content-Type: text/html;charset=utf-8
            Date: Thu, 09 Oct 2014 11:45:15 GMT
            Expires: Thu, 01 Jan 1970 01:00:00 CET
            Pragma: No-cache

            Yet, the queue item was cancelled !

            Show
            barthelemy Barthélémy von Haller added a comment - I have just tried again and could reproduce it with Jenkins 1.579. I did https://xxx.yyy.ch/jenkins/view/job/ <jobname>/buildWithParameters?module=xyz And got a 201 with a location in the header : Location: https://xxx.yyy.ch/jenkins/queue/item/1137/ I then I did : https://xxx.yyy.ch/jenkins/queue/cancelItem?id=1137 And got the following header : Status Code: 404 Not Found Cache-Control: no-cache Connection: close Content-Length: 952 Content-Type: text/html;charset=utf-8 Date: Thu, 09 Oct 2014 11:45:15 GMT Expires: Thu, 01 Jan 1970 01:00:00 CET Pragma: No-cache Yet, the queue item was cancelled !
            Hide
            danielbeck Daniel Beck added a comment -

            It makes sense to me now.

            It redirects to the referer URL, which, if that's not set, defaults to '.', or /queue/ (which isn't mean to be used interactively, so there's nothing there – 404).

            This is why I was asking where /queue/cancelItem was advertised as being part of the Jenkins API – it's not documented in /queue/api. If it's advertised nowhere, and you're just using it because it exists, then there's no reasonable expectation of URLs used by the Jenkins UI to also work outside that context.

            Show
            danielbeck Daniel Beck added a comment - It makes sense to me now. It redirects to the referer URL, which, if that's not set, defaults to '.', or /queue/ (which isn't mean to be used interactively, so there's nothing there – 404). This is why I was asking where /queue/cancelItem was advertised as being part of the Jenkins API – it's not documented in /queue/api. If it's advertised nowhere, and you're just using it because it exists, then there's no reasonable expectation of URLs used by the Jenkins UI to also work outside that context.
            Hide
            barthelemy Barthélémy von Haller added a comment -

            Ok, fair enough.

            For information I got the information about it in these two places :
            http://stackoverflow.com/questions/21021905/how-to-stop-a-build-in-jenkins-via-the-rest-api
            https://groups.google.com/forum/#!topic/jenkinsci-users/aN_WFvgTz2Y

            Is there a more standard way of cancelling a queue item ?

            Show
            barthelemy Barthélémy von Haller added a comment - Ok, fair enough. For information I got the information about it in these two places : http://stackoverflow.com/questions/21021905/how-to-stop-a-build-in-jenkins-via-the-rest-api https://groups.google.com/forum/#!topic/jenkinsci-users/aN_WFvgTz2Y Is there a more standard way of cancelling a queue item ?
            Hide
            barthelemy Barthélémy von Haller added a comment -

            Actually the second link points to a post from you

            Show
            barthelemy Barthélémy von Haller added a comment - Actually the second link points to a post from you
            jglick Jesse Glick made changes -
            Labels queue rest queue rest stapler
            Hide
            jglick Jesse Glick added a comment -

            There are lots of API endpoints which are not documented, mainly because the creator did not document them. (In this case I am at fault, though I doubt the endpoint I was replacing was documented either.)

            So this is simply a bug. Using HttpResponses.forwardToPreviousPage() is commonplace in @RequirePOST endpoints that are not expected to display anything special where the UI invoker is just something that sends a POST via a form and does not want the rendered page to change. One easy fix would be to make this method in Stapler check whether there actually is a Referer, and if not, just delegate to ok() instead.

            The proper fix would probably be to think of this as a real API and return 204 No Content, optionally with some body or status message indicating whether anything was actually canceled. It is also necessary to ensure that whatever status code is chosen, stopButton.jelly (called from two places with cancelItem) will not try to reload the page. From the use of onclick="new Ajax.Request(this.href); return false" it looks like this would already be true regardless of the status code.

            And it looks like we need a Queue/_api.jelly listing the various operations. Currently this gives only generic information.

            Show
            jglick Jesse Glick added a comment - There are lots of API endpoints which are not documented, mainly because the creator did not document them. (In this case I am at fault, though I doubt the endpoint I was replacing was documented either.) So this is simply a bug. Using HttpResponses.forwardToPreviousPage() is commonplace in @RequirePOST endpoints that are not expected to display anything special where the UI invoker is just something that sends a POST via a form and does not want the rendered page to change. One easy fix would be to make this method in Stapler check whether there actually is a Referer , and if not, just delegate to ok() instead. The proper fix would probably be to think of this as a real API and return 204 No Content, optionally with some body or status message indicating whether anything was actually canceled. It is also necessary to ensure that whatever status code is chosen, stopButton.jelly (called from two places with cancelItem ) will not try to reload the page. From the use of onclick="new Ajax.Request(this.href); return false" it looks like this would already be true regardless of the status code. And it looks like we need a Queue/_api.jelly listing the various operations. Currently this gives only generic information.
            Hide
            danielbeck Daniel Beck added a comment -

            Alright, so it's actually a bug (although I maintain undocumented -> not really API).

            Reducing priority as it's essentially cosmetic and can be ignored; maybe just disable following the bogus redirect.

            Show
            danielbeck Daniel Beck added a comment - Alright, so it's actually a bug (although I maintain undocumented -> not really API). Reducing priority as it's essentially cosmetic and can be ignored; maybe just disable following the bogus redirect.
            danielbeck Daniel Beck made changes -
            Priority Major [ 3 ] Minor [ 4 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 153175 ] JNJira + In-Review [ 178436 ]
            Hide
            deepchip Martin d'Anjou added a comment - - edited

            Running into this bug as I am adding the feature to cancel a queue item to the jenkins-rest java library. I use Jenkins 2.107.1.

            Show
            deepchip Martin d'Anjou added a comment - - edited Running into this bug as I am adding the feature to cancel a queue item to the jenkins-rest java library. I use Jenkins 2.107.1.
            deepchip Martin d'Anjou made changes -
            Labels queue rest stapler newbie-friendly queue rest stapler

              People

              • Assignee:
                Unassigned
                Reporter:
                barthelemy Barthélémy von Haller
              • Votes:
                3 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated: