This is a tricky issue, we're having trouble diagnosing it even with a debugger and could use some help.

For some reason when a search index uses the content access processor, it causes 'forum_id' to get lost from the entity cache when a forum topic is created. When the page is rendered, it shows a notice about array_flip(). If you look in database, the node seems to be saved properly with the tid of the forum, but if you look at the cache_entity table the forum_topic node is missing the forum_id property.

Something seems to happen when the content access processor is enabled such that when the node is cached, it loses the forum_id properly. Perhaps something in hook_node_access_records_alter(), but I haven't been able to track down exactly when this is happening.

Recreating the issue

  • Install Drupal using the "standard" install profile
  • Enable the forum module
  • Enable search_api_db
  • Create a db server (you can also just enable search_api_db_defaults which immediately shows this issue)
  • Create an index and add enable the content access processor
  • Create a new forum topic and save it.
  • You should see a notice about array_flip() any time you visit it.
  • Clear the cache
  • Visit the same forum topic page and the error will be gone
  • disable the content access processor
  • create a new forum topic, and there is no error
CommentFileSizeAuthor
#4 2773803_4_invalidate_node_cache.patch636 bytesdrholera

Comments

frankcarey created an issue. See original summary.

frankcarey’s picture

frankcarey commented
Issue summary: View changes
drholera’s picture

drholera commented

Checking.

drholera’s picture

drholera commented
StatusFileSize
new 2773803_4_invalidate_node_cache.patch636 bytes

I think this is the cache issue. So I found solution, we can invalidate entity cache for added node right after trackItemsUpdated() method. In this case, errors don't appear. What do you think about this solution?

drholera’s picture

drholera commented
Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 4: 2773803_4_invalidate_node_cache.patch, failed testing.

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
commented 
+++ b/search_api.module
@@ -294,6 +294,9 @@ function search_api_node_access_records_alter(&$grants, NodeInterface $node) {
+          // To prevent warnings appearing we need to invalidate entity cache
+          //for the current node.
+          \Drupal::service('cache.entity')->invalidate('values:node:' . $node->id());

Not sure if this is even the right solution, but shouldn't we use Cache::invalidateTags instead? Not sure if that invalidates the same caches though.

drholera’s picture

drholera commented

Cache::invalidateTags will work too, but I think invalidate cache that exactly we need is more correct instead of invalidating all cache records with required tag. But ve can use Cache::invalidateTags(['node_values'])

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
commented

Cache::invalidateTags will work too, but I think invalidate cache that exactly we need is more correct

, the first argument to Cache::invalidateTags is exactly the needed cache tags, so Cache::invalidateTags('node:' . $node->id() should do the same thing, this might invalidate more actual caches, but as far as I understand the cacheing layer, this is the preferred method.

I'll let @drunken monkey decide though.

mpp’s picture

mpp commented

See https://www.drupal.org/node/2784849#comment-11533091

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

I just tested this and could indeed reproduce the problem from a clean installation, so this is definitely a problem. And a pretty weird one at that – no idea how this could happen. But such things seem to occur regularly now in Drupal 8 – a thousand pieces of code running through all parts of the page request, with no chance of following what's going on.

But still, I'd vastly prefer being able to find and fix the root cause here (might easily be a Core bug – so all the more important to find it) instead of applying a workaround.
Furthermore, the proposed patch doesn't even solve the issue. You still get notices on the first page view, and a missing forum breadcrumb until you manually clear the cache. (I couldn't reproduce the notices on subsequent page requests.) So it seems we either have to come up with a better workaround, or need to find the root cause after all.

Anyone fearless enough to try debugging this? Maybe use object marking or showing the object addresses to see whether you're actually dealing with two different node objects, and then find out where the second one comes from. Otherwise, you'd have to find out at which point the forum_id field gets removed from the node object – which, since (I think) this all happens through methods in the Node class, shouldn't be too hard.

benstallings’s picture

benstallings commented
Status: Needs work » Closed (outdated)

I think we can safely say this is outdated.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.