Warning: Could not load the following items on index ...

I have search_api 1.28.0 and patch fix that issue for me.

This patch fixes the problem but in my case it introduces a huge overload. I tried a similar approach which seems to be lighter.

The last submitted patch, 7: fix_could_not_load_warning-3313569-7.patch, failed testing. View results →

Fixing previous patch errors.

Thanks a lot for reporting this issue and already finding a solution.
Both your analysis and the solution make sense, even though it’s of course unfortunate that we have to load a potentially large number of entities just to get their translations. But yes, no way around that, I fear – unless we just want people to have to live with the error in the log messages, which doesn’t really do any harm, either, as far as I can see. (Also, there is no error at all if “Index items immediately” is disabled.)
So maybe we should actually make this fix optional? Not sure. I might at least mention it in the release notes for the next release.

Anyways, attached is a slightly modified version of the patch, complete with a regression test. Please test/review, and tell me your opinion on the above.

The last submitted patch, 10: 3313569-10--referenced_entity_tracking_translations--tests_only.patch, failed testing. View results →

I added the changes from the last patch to the MR and rebased it on 8.x-1.x. I also pushed an improvement to the entity loading code: it splits the loading into chunks of (by default) 50 entities a time. This should prevent any memory issues if there are a lot of entities to load.

I think we should either commit the fix or remove the warning. Because now, for me, that warning has no meaning. I just ignore it by default because I know that most times there's no actual problem. And if people are ignoring it anyway, might as well get rid of it to reduce the noise.

Thanks for creating an MR from my patch and adding the chunking, good idea!
I added some small style fixes, would be ready to merge code-wise now in my opinion, if we want to go that route.

However, since this is just about avoiding the warnings, I think there might be a better way (i.e., one that doesn’t cause performance problems) after all: When queueing the items for reindexing, the component in question (in this case, the ContentEntity datasource) could just tell the index “hey, I’m sending you these IDs for indexing, but I’m not actually sure they exist”. That way, the index can just skip logging warnings for those IDs.
I created an MR based on that idea, please test/review.
I’m also open to other suggestions for the architecture of passing that information to the index, the one I came up with was just a method and static property on the index.

codebymikey → changed the visibility of the branch 3313569-fix-load-items-warning-v2 to hidden.

codebymikey → changed the visibility of the branch 3313569-fix-load-items-warning-v2 to active.

Yeah sure, that works for me too. Do I understand correctly that all content entities are now considered unreliable items? With that in mind, don't you think it would be better to just remove the warning? Or are there other data sources out there that could profit from the warning being present?

Do I understand correctly that all content entities are now considered unreliable items?

No, this is only for any item IDs queued for immediate indexing when it is unclear whether the object represented by that ID actually exists on the site. It would specifically be used for this scenario of marking items as “changed” when a referenced entity changes, the warning would still apply in any other circumstances, when an item is marked as “changed” (and “Index items immediately” is enabled) without the item ID also being marked as “unreliable”.

Okay, sounds good! If this solution doesn’t have the possibility to cause performance problems it's probably the better one.

Good to hear, thanks for the feedback!
Since we’re adding a new API here, which is then pretty much set in stone, I’d still like to leave this open for a few weeks in case anyone wants to comment on the proposed architecture for this (even though the change is pretty small). I’ve also pointed people on Slack to this issue.

drunken monkey → closed merge request !53

Thanks for merging HEAD, that seems to have fixed the CI fails!
I think that was long enough for feedback, so I went ahead and merged this.
Thanks again!

Automatically closed - issue fixed for 2 weeks with no activity.