none
Help reproducing a bug - Activity status stuck in pending mode, Service Request still "in progress"

    Question

  • I have noticed SRs getting stuck with an activity in pending while the SR is still "In progress". What I reckon is happening is

    1. SR with a single MA is created (from portal or in console)
    2. Analyst opens the MA
    3. Analyst completes the MA (does NOT click OK/Apply)
    4. Analyst opens the SR - using the link in the top banner
    5. Analyst adds one or more activities to the SR
    6. Analyst clicks "OK" on SR
    7. Analyst clicks "OK" on MA

    What happens next is that the added activities are stuck in pending while the SR is stuck in progress. Can anyone verify this on their system(s)?

    Thursday, June 19, 2014 11:46 AM

All replies

  • your user is, very carefully, avoiding the double update limitations that are in place to prevent this type of error, and is causing a race condition between the Activity Added and activity status changed workflows.

    in short, your user is submitting an update to the SR and an update to the MA in the same workflow cycle, both workflows are firing and don't see the state they expect, so are crashing or choosing to make no change (these workflows are a bit of a black box, since no source is published).

    unfortunately the Service Request activity workflows are very fragile, and do not have a lot of latitude in the types of states they will accept. for another example, creating a SR through the SDK API with a null status (instead of new) will cause the workflows to do this too.

    if this is something that happens rarely, then you should report it on connect, and manually fix SRs that are in an invalid state when they are reported. if you are seeing this a lot, then it might be in your interest to create a patrol workflow that looks for SRs that are in this state (say, once a day or so) and manually sets the first pending activities status to active or rerun, in order to keep service times down for these users.

    Thursday, June 19, 2014 1:28 PM
  • your user is, very carefully, avoiding the double update limitations that are in place to prevent this type of error, and is causing a race condition between the Activity Added and activity status changed workflows.

    in short, your user is submitting an update to the SR and an update to the MA in the same workflow cycle, both workflows are firing and don't see the state they expect, so are crashing or choosing to make no change (these workflows are a bit of a black box, since no source is published).

    unfortunately the Service Request activity workflows are very fragile, and do not have a lot of latitude in the types of states they will accept. for another example, creating a SR through the SDK API with a null status (instead of new) will cause the workflows to do this too.

    if this is something that happens rarely, then you should report it on connect, and manually fix SRs that are in an invalid state when they are reported. if you are seeing this a lot, then it might be in your interest to create a patrol workflow that looks for SRs that are in this state (say, once a day or so) and manually sets the first pending activities status to active or rerun, in order to keep service times down for these users.

    I appreciate the explanation. I was expecting an explanation along the lines of this.

    I would however like to know if others can reproduce this behaviour.

    I must agree that this is not an intended use of a Service Request workflow as I have informed console analysts of. Nonetheless it should be possible for the workflow engine to detect these issues and correct the workflow (ie. a bug).

    Friday, June 20, 2014 9:36 AM
  • I just realized a simple workaround. Put the SR/CR on hold and resume. Will "kickstart" the workflow engine.
    Thursday, June 26, 2014 1:14 PM
  • as an FYI, that work around will only work if the service request and all of the activities are in a legitimate state. if any of the work items are left in a non-standard status, putting the SR on hold and then resuming it (essentially triggering the Service Request Status Changed workflow to re-evaluate the SR) will have no effect.
    Thursday, June 26, 2014 4:40 PM
  • Can you provide an example of an in-legitimate state?
    Friday, June 27, 2014 7:35 AM
  • Two activities with the same Sequence ID, two activities in Running status, SR has a Null status, activity statuses are out of order (compared to SequenceIDs). basically any state that shouldn't be reached in normal operations. 
    Friday, June 27, 2014 12:03 PM