Warning remains on status page after all entities initialized

If you run the below code, you can get a list of uninitialized entities for each entity type:

function get_all_uninitialized_entity_ids() {
  /** @var \Drupal\cached_moderation_state\BatchUpdateHandlerInterface */
  $batch_update_handler = \Drupal::service('cached_moderation_state.batch_update_handler');
  /** @var \Drupal\cached_moderation_state\FieldConfigHandlerInterface */
  $field_config_handler = \Drupal::service('cached_moderation_state.field_config_handler');

  $entity_ids = [];
  foreach ($field_config_handler->getModeratedEntityTypes() as $entity_type) {
    $bundles = $field_config_handler->getModeratedBundlesForEntityType($entity_type);
    $entity_ids[$entity_type->id()] = $batch_update_handler->getEntitiesForEntityType($entity_type->id(), $bundles, TRUE);
  }

  return $entity_ids;
}

echo '<pre>' . \htmlentities(\var_export(get_all_uninitialized_entity_ids(), TRUE)) . '</pre>' . \PHP_EOL;

Unfortunately, I can't help diagnose the issue that's preventing these from being initialized. Typically there's a hook implementation that prevents the normal operation of this module.

If you find out something interesting, feel free to report back.

@clayfreeman

Thanks, I will try that when I'm in the office tomorrow, I'm almost certain everything has been initialized it's just not seeing that they are, but I could be wrong on that. Anytime I query cached_moderation_state I get the correct results I'm looking for!

I'll post what I find after running the code..

@clayfreeman

Well...interesting! Something definitely isn't right.

After running your code an array of 110 nodes are returned (as per the status page suggests) "however" the nodes it lists do not exist!
No entities either (media, paragraphs, comments, etc.) none have matching ID's to the node ID's returned which they shouldn't be considering no other entities besides 2 content types are using content moderation.

And out of the 2 content types (using content moderation) all nodes have been initialized and none are listed in the returned array accept for the first 5 - but I'm pretty sure that is just a coincidence. The next node I create would make it the 6th ID listed..

Here is what was returned:

array:1 [▼
  "node" => array:110 [▼
    0 => "node:170"
    1 => "node:171"
    2 => "node:172"
    3 => "node:173"
    4 => "node:174"
    5 => "node:175"
    6 => "node:176"
    7 => "node:177"
    8 => "node:178"
    9 => "node:179"
    10 => "node:180"
    11 => "node:181"
    12 => "node:182"
    13 => "node:183"
    14 => "node:184"
    15 => "node:185"
    16 => "node:187"
    17 => "node:191"
    18 => "node:192"
    19 => "node:193"
    20 => "node:194"
    21 => "node:195"
    22 => "node:196"
    23 => "node:197"
    24 => "node:198"
    25 => "node:199"
    26 => "node:200"
    27 => "node:201"
    28 => "node:202"
    29 => "node:203"
    30 => "node:210"
    31 => "node:211"
    32 => "node:212"
    33 => "node:213"
    34 => "node:214"
    35 => "node:215"
    36 => "node:217"
    37 => "node:218"
    38 => "node:220"
    39 => "node:223"
    40 => "node:225"
    41 => "node:226"
    42 => "node:232"
    43 => "node:233"
    44 => "node:234"
    45 => "node:235"
    46 => "node:236"
    47 => "node:237"
    48 => "node:238"
    49 => "node:239"
    50 => "node:240"
    51 => "node:242"
    52 => "node:243"
    53 => "node:244"
    54 => "node:245"
    55 => "node:246"
    56 => "node:247"
    57 => "node:248"
    58 => "node:249"
    59 => "node:250"
    60 => "node:251"
    61 => "node:252"
    62 => "node:253"
    63 => "node:265"
    64 => "node:271"
    65 => "node:274"
    66 => "node:276"
    67 => "node:277"
    68 => "node:278"
    69 => "node:279"
    70 => "node:280"
    71 => "node:281"
    72 => "node:304"
    73 => "node:305"
    74 => "node:309"
    75 => "node:310"
    76 => "node:311"
    77 => "node:312"
    78 => "node:313"
    79 => "node:314"
    80 => "node:315"
    81 => "node:316"
    82 => "node:317"
    83 => "node:318"
    84 => "node:319"
    85 => "node:321"
    86 => "node:322"
    87 => "node:323"
    88 => "node:324"
    89 => "node:325"
    90 => "node:326"
    91 => "node:327"
    92 => "node:328"
    93 => "node:329"
    94 => "node:330"
    95 => "node:331"
    96 => "node:335"
    97 => "node:339"
    98 => "node:340"
    99 => "node:341"
    100 => "node:343"
    101 => "node:345"
    102 => "node:347"
    103 => "node:349"
    104 => "node:351"
    105 => "node:353"
    106 => "node:355"
    107 => "node:358"
    108 => "node:360"
    109 => "node:363"
  ]
]

Currently I only have nodes with ID's up to 175, next node that will get created will be 176, Node 175 was created yesterday after submitting this issue so it didn't even exist yet and status page listed 110 entries. Nodes 170, 172-174 are for a content type that isn't using content moderation and node 171 was the last node created before installing this module that uses content moderation.

So, like I been saying the whole time everything seems to have initialized because if I take node 171 and change its moderation state and query with cached_moderation_state I get the correct result same for 175 and any node that uses content moderation that was created before installing cached_content_moderation it always returns the correct results. This list of 110 nodes were I have no nodes with ID's starting after 175 is definitely weird and doesn't make any sense.

Any thoughts? Something else to try perhaps?

I should note that for revisionable entity types, the list of IDs returned will be revision IDs instead of entity IDs. I wonder if you may have some dangling revisions in your database for content which has since been deleted?

My thoughts were actually headed towards this being related to revisions. Was just about to update this issue asking if it could be somehow revision related. So I did a quick check on my existing content and any of my current nodes when checking loadedRevisionID viewing the devel tab for some nodes that use content moderation and they aren't in the list of 110 (so again everything looks to be working properly) so I'm going to guess maybe somehow there are dangling revisions. Because I'm not getting any errors or problems for anything and all hooks seam to be firing fine no issues as well. Plus the only thing I really use for hooks for right now is to launch events I have subscribers too (when you mentioned a hook could be preventing your module from updating entities I checked through everything custom on my end, nothing interferes nor should it with cached_moderation_state when running the batch initialize.

I'll have to run through the database first thing next week to see if I can find dangling revisions with ID from the list returned. I'll post what I find. Feels like the most logical explanation.
- Thanks on that..

OK.. I think I've got things sorted and should someone find themselves in the same boat...

This issue appears related to these issue:
https://www.drupal.org/project/drupal/issues/2978521 🐛 Remove orphaned (dangling) entity references when an entity is deleted Active
https://www.drupal.org/project/drupal/issues/2723323 →

Apparently Drupal currently does not cleanup dangling entity references and a slew of contributed modules are out there to handle some aspects of it depending on exactly what you want to do. There appears to be a few different views on why orphaned and dangling entity references should be removed and then others with why they shouldn't be (worth reading those issues for details).

But because they don't just get removed (or at least in my case some didn't) which is depended on several variables it has caused the notice of pending entities remain to be initialized by this module.

I was able to use a contrib module "node_revision_delete" https://www.drupal.org/project/node_revision_delete → by adding the option to delete revisions after 0 exist prior and letting it queue all older revisions (queue manager and queue ui help to see what was going on), then running cron. After cron ran I checked the status page and there is no-longer a warning listing 110 entities still needing to be initialized.

For the site in question even though some entities use workflow to utilize moderation state, revisions aren't required and aren't actually used - so purging any revisions (which probably exist from initial testing and content configuration testing) were all deleted.

I think even though this module listed 110 entity references to be initialized they were attached to 35 deleted nodes because the queue listed 35 entries total to be deleted, but I'm not entirely sure how node_revision_delete sets the ID for the queue item only about half of them matched up to the list of 110 IDs.

So in all I guess this technically isn't a bug with this module. Perhaps this info can help create a method for were this module could filter out orphaned or dangling revisions. At the very least I can't imagine I'll be the last for this to happen to in the future and this information will help!

Great, glad you were able to figure it out. I don't think I want to build a mechanism for detecting these dangling revisions at this time, as it falls outside of the scope of concern of this module.

Closing this out for now since there's no action item.