EBMS Tickets

Should be OK now. Please try again.

Confirmed, it is no longer stuck. Thanks!

Another citation has gotten stuck in my queue. 

EBMS ID: 948719, first citation listed in queue with no filter applied

Decided to add to this ticket since this ticket was not yet closed. If the frequency of citations getting stuck in my queue continues to increase, let me know if you would rather have a new ticket for each occurrence or maybe one ticket that we keep open.

more details: citation got stuck after adding the liver cancer prevention topic at about 9:50am this morning

The article should no longer be stuck in the queue for the Liver Cancer Prevention topic.

Note to programming staff: I have found evidence indicating that the cause of these anomalies is the presence of duplicate state entries likely resulting from double-clicking on the submit button for a request instead of single-clicking. In this case the request would have been an import request, causing two rows to be created in the state table with the Ready for initial librarian review state. When the librarian review was performed, a new row was created for the topic with the Passed initial librarian review state. Before the new state is added, the code loops through all of the existing state rows for the article-topic combination and turns off the current flag so that only the rows which is about to be added will have that flag turned on for the article-topic combination. However, because this work is being done at the object level for the Drupal entity, rather than directly examining manipulating the database rows, the existing row with the current flag turned on isn't always processed, because the Drupal entity API views seems to be regarding the state row with the same state value, board, topic, user, and entry date/time as duplicate representations of the same state, and only uses one of the rows to represent the state for the code looping through to turn off the current flag for preexisting states. As a result, if the row presented in the loop is not the one with the current flag turned on, after the new row is added to the state table there will be two states for the topic which are marked as current, so when the queue is being built, the software thinks this topic is still "ready for initial librarian review." I am doing some investigation into avoiding this condition by either using locks to prevent the creation of the duplicate rows, or having the loop to clear the previous current flag work at the database level instead of the entity object layer, or both. The second approach (unlocking at the database layer) might be safer, as it would avoid the risk of stale locks left by aborted transactions blocking subsequent user requests. I need to find out how well mixing lower-level database manipulation will interact with the rest of the state-management code, which works with the higher entity API.

Confirmed. Citation is no longer stuck in queue.

I have modified the Article::addState() method, through which all changes to the state table are required to go. I have added a lock which prevents multiple calls from being handled at the same time. If a second call arrives while another is being processed it waits until the lock is released, which generally happens very quickly. Exception handling has been added to ensure that no matter what problems are encountered, the lock is released.

The method fetches the current state for the article-topic combination and if the request is for the same state value as that recorded as the "current" state, and if the current request was submitted within five seconds of that "current" state, then an error is logged and NULL is returned instead of a reference to a new State object. I originally considered blocking requests to put the article-topic combination in the same state as the current state, regardless of how recently that state was recorded, but there are use cases in which it is necessary to submit a request to add a new state (for example, changing the decision for the Final board decision state).

I have identified and marked the duplicate states entered by double-clicking on the Submit button as inactive. After the code modifications have been installed on PROD I'll do another check to make sure any new duplicates are handled the same way. After that point the problem shouldn't arise again.

I also added some Javascript to the import page to disable the Submit button after it has been clicked to prevent double-clicking on that page. We'll need to test that to make sure it doesn't break anything.

Finally, I also noticed that sometimes users have used the Back button to go back to a review form they have already submitted and submit the form a second time (or more), rather than use the re-built queue page which will have removed the articles for which decisions have already been recorded. I don't believe we can do anything about that problem, other than discouraging users from doing that. That behavior does not cause articles to get stuck in the queue the way double-clicking on the Submit button does, it just adds clutter to the state history for the articles.

Installed on EBMS DEV.

https://github.com/NCIOCPL/ebms/commit/c52cc2d

~boggessc  reported some problem with the import pages, caused by the Javascript I had added to avoid duplicate submissions. I have backed out that code. Please let me know if you still see problems with those pages on EBMS DEV. You made need to do a hard refresh (holding down the shift key when you press the Refresh icon).

Tested again and looks good on dev.

This is difficult to test as it is difficult to recreate. In my time reviewing on QA nothing got stuck in the queue.

Closing ticket. If issue happens again, we will create a new ticket. Thanks!