Multiple request items being created on catalog item form submit

[bennyb]

Hi there,
we've noticed an issue lately (seems to be around Berlin release) that on occassion, when somebody submits a catalog item, multiple request items get created under the same request.

Sometimes 1 and 2 extra request items are created and these "phantom" request items do not have all the original variables attached.

This only seems to happen on occassion and has occured for a few of our different catalog items. Initially we suspected it may be a result of someone attempting to attach something to the catalog item and then clicking the back button and resubmitting the catalog item again, but we noticed it occured on a catalog item without adding attachments.

So far we have only seen the issue occur in IE browser.

Regards,
Ben

[bennyb]

After some further investigation this behaviour seemed to be caused when a user submits a request item and the form "hung". The user then re-submitted the form, but because a cart and item already existed, a new item was created which made it look like duplicate request items being submitted.

"CatalogTransactionOrder" is the script include which is called when the "Order" button is clicked. As a workaround, we modified this to clear the cart each time:

gs.include("PrototypeServer");

var CatalogTransactionOrder = Class.create();

CatalogTransactionOrder.prototype = {

       initialize : function(request, response) {
          this.request = request;
          this.response = response;
       },

       execute : function() {
          var c = Packages.com.glideapp.servicecatalog.Cart();

        // Added this line below to clear the cart each time:
        c.empty();
  
        c.addToCart(this.request);

         return new CatalogTransactionCheckout(this.request, this.response).execute();
       }
}

This is only a workaround though, as if in the future we start using the "Add to Cart" functionality, this line could potentially clear carts that have legitmate items in them.

I have raised a ticket with Service-now to investigate adding a try/catch block around the addToCart/CatalogTransactionCheckout section of code in this function which would be a better solution...

[bennyb]

The actual cause was this was not the form hanging on submit, but the quota manager cancelling reference completers.

This was indicated in our logs:

Cancelling transaction /xmlhttp.do (cancelled by other transaction): Thread http-bio-12501-exec-38 (user, CCA3B83D55CC4500787138EEB3BFE8AF), after 183ms

Service-now have indicated this is known problem which is fixed with Berlin patch 3.