Mismatched language saved in solr

Oh, yes, that sounds quite bad. But no, I have never heard of something like that before.
For the sake of debugging, could you check whether the attached patch resolves the issue for you? That would be more or less my only guess what could be happening: some code somewhere manipulating the entity/translation in question to point to a different language. Then you might be able to find the code responsible.

(As said, the patch is just for debugging purposes. I don’t think I’d commit it as-is, as it would decrease performance for everyone else. However, if it does help but you can’t figure out the root cause of the problem, feel free to just keep it apply to the module on your site – better to have a little less performance during indexing/searching but correct search results.)

Hi! Thank you so much for the help! The patch works and all mismatched documents are gone.
I already had something similar implemented in the the getOriginalObject method.
As you said, better to have a small performance decrease and no duplicates/omissions in search results :)

I'll try to do some debugging to get to the root couse of the issue.

This patch appears to be a safe change to make.

I don’t think I will commit the patch in this form, for the reasons stated in #2. I don’t want want to make searches slower for lots of people for which the current code works.

I'm suffering from the same problem on a site. The setup is this: two languages, negotiation happens on domain (not sure whether that contributes to the problem or not).

At first I thought the patch in 🐛 Rendered HTML Output doesnt respect activeLanguage completely Needs work solved the problem, which it didn't entirely. So, I started looking into the index and saw that the ss_search_api_language value didn't necessarily matched that language in the search api id.

With this patch, things started acting as they should and the languages in both values match, and they would only show up on the site in the right language (before, some of the content appeared twice in the same view, e.g. in dutch, because the language contained nl)

As far as I can see, the following might be the problem: whether or not the original language of the entity matches the default language of the site. The entities that had the problem had their original/initial language set on english, where the default language of the site is dutch.

It kind of relates with 🐛 Rendered HTML Output doesnt respect activeLanguage completely Needs work in the same way that the entity which is being rendered/indexed isn't necessarily, well, 'right' .. :)

@swentel:

As far as I can see, the following might be the problem: whether or not the original language of the entity matches the default language of the site. The entities that had the problem had their original/initial language set on english, where the default language of the site is dutch.

For those items, do you get a Dutch item ID (entity:node/…:nl) with "ss_search_api_language":"en" or the other way round?

Also, can you find out any less “costly” way of acquiring the correct entity adapter than cloning the entity, in that place in the code?
Or, for you, does this maybe look like a Core issue that needs to be reported and resolved there?

Maybe something like the attached works, where I at least check to make sure we need the clone fix before cloning?

Finally, is someone able to provide a failing test case for this?

For those items, do you get a Dutch item ID (entity:node/…:nl) with "ss_search_api_language":"en" or the other way round?

What happened is that an entity which has English as the default langcode, where the site's default language is Dutch, became indexed with the dutch language, so, the other way around.

I'll try to test the patch in the coming days.