EBMS Tickets

I have also logged out of the EBMS, opened a new browser and logged in again and the citation is still in my queue.

Review decisions for this citation were recorded at about 1:10pm today.

Investigating (with fingers crossed that no one does anything which knocks this out of the queue before I figure out why it's there). 😛

Can you provide any details, no matter how insignificant they may seem about what was done when assigning the decisions for this article? Multiple topics assigned at once, for example? I'm particularly interested in Childhood Astrocytomas, for which two states are marked "current" which shouldn't ever happen for a given article/topic combo.

All the topics had been assigned upon import. I did not add any to this citation.

While reviewing the citation, I clicked on the pmid to see the abstract and mesh in pubmed.

I rejected brain & spinal as well as late effects and accepted all the others.

I was eating lunch while reviewing so the queued decisions were probably held on the page longer than usual.

And before eating my lunch, I left my queue open while making my lunch which was maybe 15 minutes or however long it takes to make a salad 🙂

And I was also possibly flipping back and forth between the ebms and teams chat and/or outlook. But this is something that is not unusual/different to happen while I am reviewing.

This citation was reviewed along with the 9 others on the page. I cannot remember if I added topics to any of the other 9 or not. 

Otherwise it was reviewing per usual.

FYI after I added this ticket, I opened the dev tool console while I continued reviewing just in case it happened again. It didn't but I did encounter the same/similar issue reported in ticket 743 but with an unsorted, filtered by title list of citations with 40-50 citations in list. This is not the first time I have experienced this issue in prod. In fact I have been trying to recreate it in QA but cannot so it is likely your fix to ticket 743 has resolved this issue as well. BUT I did get an error in the console when my decisions were not recorded which might be some new data for you. Although this error may have nothing to do with the issue reported in this ticket. Thought I'd mention it just in case. see screenshot.  decisions not being recorded console error.docx

Programmer's Notes

So I have a record for myself of what I've determined by examining the source code, here's an annotated copy of the relevant portions of that code, snipping out the bits that don't matter in this context, with copious comments added explaining what it's doing, and stable links to the full source code.

Where the user clicks on the Submit button, the ReviewQueue::submitForm() method is invoked.

  public function submitForm(array &$form, FormStateInterface $form_state) {

    // Find out which button was clicked.
    $trigger = $form_state->getTriggeringElement()['#value'];

    // This next test will pass because the Submit button was clicked.
    if ($trigger === 'Filter' || $trigger === 'Submit') {

      // This test will also pass, for the same reason.
      if ($trigger === 'Submit') {
        // snip ....

        // Collect and decode from the JSON each decision the user queued up.
        $decisions_json = $form_state->getUserInput()['decisions'] ?? '{}';
        $decisions = json_decode($decisions_json, TRUE);

        // For each decision load the article and apply the new state.
        foreach ($decisions as $key => $decision) {
          // snip ...
          $article = Article::load($article_id);

          // We'll dive into this call, because this is where the old state should be marked
          // as not current any more.
          $article->addState($state, $topic_id, $uid, $now);
          $article->save();
          $this->messenger()->addMessage('Queued decisions have been applied.');
        }
      }
      // snip ...
    }

    // We can ignore the rest of this method, because this isn't the button which was clicked.
    if ($trigger === 'Save as Default') {
      // snip ...
    }
  }

Drilling down into the Article::addState() method, which we know was reached for this article (EBMS 904544, Supratentorial CNS-PNETs in children; ....) and topic (Childhood Astrocytomas) because the decision ({}passed_init_review{}) for that combination was recorded and marked active and current:

  public function addState(
    string $text_id,
    int $topic_id,
    int $user_id = NULL,
    string $entered = NULL,
    string $cycle = NULL,
    string $comment = NULL
  ): object {

    // snip some housekeeping code ...

    // Find the `ArticleTopic` entity.
    // Each of the article's State entities will be found with the
    // topic for which it was recorded.
    $article_topic = NULL;
    foreach ($this->topics as $candidate) {
      if ($candidate->entity->topic->target_id == $topic_id) {
        $article_topic = $candidate->entity;
        break;
      }
    }

    // Create a new one if it's missing.
    // We know we won't get into this block of code, because there's no
    // way for an article to presented in the librarian's queue for a given
    // topic if that topic hasn't already been assigned to the article.
    $new_topic = FALSE;
    if (empty($article_topic)) {
      // So snip the rest of this block ....
    }

    // Otherwise, make any necessary tweaks to the topic's existing states.
    // Here we're walking through every one of the states which has ever
    // been assigned to the article for this topic.
    else {
      foreach ($article_topic->states as $state) {
        $state = $state->entity;

        // We set a flag to remember if any changes have been made to this state.
        $modified = FALSE;

        // This next test would have passed for the ready_init_review state, because
        // having that state be current is how this topic was presented for a decision
        // for this article in the librarian's queue.
        if (!empty($state->current->value)) {

          // So we would have turned off the "current" flag for this state ....
          $state->set('current', FALSE);

          // ... turned on the flag to say we need to save it.
          $modified = TRUE;
        }

        // This next test is to see if the state is one which logically comes AFTER the
        // state we're about to add. The test will fail for this case because ready_init_review
        // logically comes BEFORE the passed_init_review state we're about to add.
        if ($state->value->entity->field_sequence->value >= $sequence) {
          // so we can snip the rest of this block
        }
        if ($modified) {
          // And we know this will happen, because we just set the $modified flag to TRUE.
          // The Entity::save() method is Drupal's, not EBMS code, so if that didn't really
          // save the change we just made with $state->set('current', FALSE) then the
          // problem is deep in the bowels of Drupal.
          $state->save();
        }
        // snip ...
        }
      }
    }

    // Prepare to create the new `State` entity.
    // We've already passed the part we're interested in, so snip most of the rest ....
    // But this is where the new state gets added:
    $state = State::create($values);
    $state->save();
    // snip ....
  }

tl;dr: I can't see how this can have happened, even though it clearly did.

Next Steps

Try to get as much information about what was done leading up to the problem so I can attempt to reproduce it on a non-production system.

Whether or not we can reproduce this on a lower tier, whether we every discover what caused it, whether it happens in production: what I expect to happen is that the problem will resolve itself when a decision is made from the abstract review.

This citation does appear in the Batch Publish list for all three accepted summary topics. So I suggest we go ahead and publish it and see if the new state change kicks it out of my queue. I'll do this with the console open and let you know what happens.

I also wonder if it is worth importing this citation into QA with all the same topics and then review it to see if maybe there is something happening that is citation specific.

🙂 well this just got even more odd..

From the Batch Publish page, I filtered the list by pediatric board and a list of 23 citations is generated. This citation is #20. As soon as I click on the check box next to one of the summary topics, the page flashed a bit and the citation disappears. And I have attached what appears in the console when it happened.

If I reset and refilter by board the citation reappears.

I just reviewed the full article history for this citation and it looks like Jeff imported it twice on the same day as Childhood Astrocytoma. This sort of thing can happen either as human error but typically it does not cause a problem or at least has not to date to my knowledge.

But thought I'd mention it just in case it is relevant.

Tried to recreate on DEV. Citation was imported twice for Astro and once for the other topics but it did not get stuck in my queue when reviewed or disappear from the batch publish page. So cannot recreate.

I discovered that there were only two article/topic combinations in the production database with more than one state marked "current" and none in any of the lower-tier databases. Both of those articles were imported twice in two import requests recorded as having been submitted in the same second (2023-03-29 00:03:55): import jobs 43988 and 43989. I am unable to reproduce the condition of an article/topic combination having more than one "current" states on the lower tiers, no matter how closely together I bang on the Submit button. I have resolved the condition by clearing out the "current" and "active" flags for the two duplicate states. The other article is EBMS 904598 (PMID 36826144): Clinical, Morphological, and Molecular Study on Grade 2 and 3 Pleomorphic Xanthoastrocytoma (Zhang et al.).

I reviewed EBMS: 904598 (PMID: 36826144) and published with no problems. 

EBMS ID: 904554 (PMID: 36895035), the stuck citation, was no longer in my queue after your fix and I was able to publish it from the Full Article History page.

If we cannot reproduce these citations with "current" and "active" flags for the two duplicate states and fix whatever is creating the duplicate states, should we run a report each month after all our imports to look for these citations or do we wait and see if and how often they occur?

I can certainly run such a report periodically. It's encouraging that it's only happened once.

... fix whatever is creating the duplicate states ...

Well, "whatever" would be double-clicking the Submit button on the Import Articles from PubMed form. We can ask people not to do that, but I don't think we can prevent them from doing it. 😉

I'll mention this to Jeff. My guess is he did not even realize he had double clicked the submit button.

I probably wouldn't have noticed that late at night either. 😃