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

Queue item cancellation via REST api works but returns a 404

    XMLWordPrintable

Details

    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

            Actually the second link points to a post from you

            barthelemy Barthélémy von Haller added a comment - Actually the second link points to a post from you
            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.

            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.
            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 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.
            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 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.
            pierrebtz Pierre Beitz added a comment -

            I also lost some time with this return code before seeing this issue, proposed some change to address this

            pierrebtz Pierre Beitz added a comment - I also lost some time with this return code before seeing this issue, proposed some change to address this

            People

              pierrebtz Pierre Beitz
              barthelemy Barthélémy von Haller
              Votes:
              3 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: