Stuck Jobs

What is a Stuck Job?

As the name implies, a stuck job refers to a job that is not able to successfully complete. Stuck jobs can also be considered 'failed' jobs. Whilst Caseflow has several jobs and any job has the potential to become 'stuck', the most common occurrence of stuck jobs that have come up within Caseflow occur within DecisionReviewProcessJob and involve RequestIssuesUpdates.

What is a Request Issues Update?

A RequestIssuesUpdate is an object that houses the IDs of Request Issues that a user is attempting to make edits to within Caseflow. Whenever a user is on the edit issues page within caseflow, they will be presented actions that they can make. There are 5 possible actions and they are: add an issue, correct an issue, edit an issue, remove an issue, or withdraw an issue. The user can make multiple edits at one time. When the user has made all desired actions, they will then click on a Save button within the edit issues page. This results in a new RequestIssuesUpdate object being generated by the controller. The Request IssuesUpdate is then passed to the DecisionReviewProcessJob as an argument. The DecisionReviewProcessJob carries out all the actions that the RequestIssuesUpdate needs to have made. The RequestIssuesUpdate object has multiple attributes it uses to determine what actions need to be carried out. I will describe how it determines each action below:

1. Added Issues. The RequestIssuesUpdate Object determines if any issues were added to the claim by comparing the before_request_issue_ids column to the after_request_issue_ids column. These two columns contain arrays of the Request Issue IDs that were present both before the user clicked the save button and after the user clicked the save button. If an ID is present in the after_request_issue_ids column and not present in the before_request_issue_ids column, then that means that the Request Issue tied to that id has been added and needs a correlated contention for it created in vbms.
2. Removed Issues. The RequestIssuesUpdate calculates the removed issues in the same way as the added issues, but in reverse. Meaning that if there is an id present within the before_request_issue_ids column and not in the after_request_issue_ids column, then the Request Issue tied to that id is a Request Issue that has been removed and needs its correlated contention in VBMS to be deleted.
3. Edited Issues. The RequestIssuesUpdate object has a column called edited_request_issue_ids that has an array of all the ids that have an edited description. The Request Issues with these ids have an attribute called edited_description that contains a string with the new description. The correlated contention in VBMS will then receive the updated edited description.
4. Corrected Issues. The RequestIssuesUpdate table has a column called corrected_request_issue_ids that has an array of all the ids of corrected request issues. The way these are handled is a bit complicated, but essentially the original request issue receives a closed_status of ‘no decision’ and a new corrected Request Issue is made in Caseflow (a new correlated contention is also made within VBMS).
5. Withdrawn Issues. The RequestIssuesUpdate object has a column called withdrawn_request_issue_ids that has an array of all the ids that have been withdrawn. The Request Issues that contain these ids will receive a closed_status of ‘withdrawn’ and the correlated contention will be deleted within VBMS.