Error "Column 'langcode' in field list is ambiguous" thrown due to TranslationLanguageRenderer not rendering a field from a relationship

A few notes:

a) I originally came across this issue when doing manual testing in #2429447-50: Use data table as views base table, if available.

b) The exception in the issue summary is from joining on a taxonomy reference field. Any Relationship will do, but just noting that the specific query exception posted there is from a taxonomy join.

c) Currently to trigger this problem you need to add a field to the entity you are joining, such as adding a text field to Users, and joining on User, and then display that custom field you created.

d) And it is only a problem for field-based views.

I'll update the issue summary.

I couldn't reproduce:

1. Installed language, content_translation.
2. Enabled content translation for nodes and users.
3. Followed the issue summary "Example" instructions.
4. Created a user, filled the field.
5. Translated the user and the field.
6. Created a node with that user as author.
7. Translated it.
8. The view shows 4 rows (no exception): node en-user en, node es-user en, node en-user es, node es-user es.

That is very interesting. I wonder how/when it would have been fixed? I was not able to make the problem unless I made a view with a relationship between Node and another entity, and there was a plain Text field on the second entity that was translated, and the view was field-based and displaying that field on the second entity. Can you verify that is what you tested?

I think this might have been fixed by #2454145: Replace user_name handler with Field API formatter, which added a relationship parameter to the renderer ::query method:

http://cgit.drupalcode.org/drupal/tree/core/modules/views/src/Entity/Ren...

OK then, let's close this then. Thanks!

Yay!

I just saw this pop-up again in #2726507: Integrity Constraint Violation Exception when adding another language. Could be an issue with revisions? Not sure.

In this case it appears as if the langcode field is added twice, once (correctly) by {node_revision} and once incorrectly by {users}.

The issue may be that there are _two_ relationships in this view. Note the broken fieldAliases.

Interesting. In my case, the View has 5 fields. 4 use a relationship. One does not. It's that last one that causes the error.

I can fix that in the View by adding the missing relationship, but this still seems like a bug.

This never got bumped when versions changed.

@timplunkett, @alexpott, @dawehner, @xjm and I discussed this in a triage session at DrupalCon Dublin. This is an exception thrown in the UI with a few simple steps. We agree this is major priority.

The fix for #2457999: Cannot use relationship for rendered entity on Views adds relationship handling to TranslationLanguageRenderer so would expect this to be fixed when that lands.

The same error occurs in a far easier example then in OP, using a View of Content Revisions
- Add a Field of type "List (integer) (module: options)" to a content type. Add a few keys. You may or may not use 'key-value combinations.
- create some content
- Create a view of Content Revisions, add the new field, add an exposed filter for the field to the view.
- Show the view: all is fine:
- Apply the filter: the following error appears:

Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1052 
Column 'langcode' in field list is ambiguous: 
SELECT 
node_field_revision.vid AS node_field_revision_vid, 
node_field_revision.vid AS vid, 
langcode AS langcode 
FROM {node_field_revision} node_field_revision 
INNER JOIN {node_revision__field_listonetoten} node_revision__field_listonetoten 
ON node_field_revision.vid = node_revision__field_listonetoten.revision_id 
AND (node_revision__field_listonetoten.deleted = :views_join_condition_0 
AND node_revision__field_listonetoten.langcode = node_field_revision.langcode) 
WHERE ((node_revision__field_listonetoten.field_listonetoten_value = :node_revision__field_listonetoten_field_listonetoten_value)) 
AND (node_field_revision.status = :db_condition_placeholder_2) 
ORDER BY node_field_revision_vid DESC LIMIT 21 OFFSET 0; 
Array ( [:node_revision__field_listonetoten_field_listonetoten_value] => 7 [:db_condition_placeholder_2] => 1 [:views_join_condition_0] => 0 ) in Drupal\Core\Database\Connection->handleQueryException() (line 682 of core\lib\Drupal\Core\Database\Connection.php).

The patch in #1 (which is outdated, so applied by hand manually) does not solve the problem.

I tested the patch mentioned in #17 and that didn't fix this issue for me when it was manifested in #2862041: Provide useful Views filters for Content Moderation State fields.

Here is a test that proves this still exists, inspired by #1 but using a new view with a revision base table.

Hopefully helps work towards a solution for this.

Here is a solution which fixes the problem for me, but it doesn't feel right for some reason.

Working a bit on this

This is blocking #2862041: Provide useful Views filters for Content Moderation State fields, so it's a blocker as well.

After digging into this, I think the issue we are having in #2862041: Provide useful Views filters for Content Moderation State fields is not actually related to this one, it's more about properly supporting entity revision views at entity row renderer level. Therefore I'm going to reopen the issue that was marked as duplicate and move there.

Attaching an updated version of the tests in #1 (plus some clean-up) applying to 8.4.x. I suspect this may be actually fixed by #2457999: Cannot use relationship for rendered entity on Views or should at least be postponed to that.

Just tried the most recent patch in #2457999: Cannot use relationship for rendered entity on Views and it doesn't resolve this problem. #22 is a quick fix for now, for anyone landing on this issue.

@samuel.mortenson: Try #2896381: "TranslationLanguageRenderer" uses the wrong table for the "langcode" column with entity revision views if you're on 8.3.

Rerolled patch for 8.9.0 without tests, because I had errors

Adding what this is postponed on to the issue summary.

The blocking issue has been fixed. I'll un-postpone this.

There is some suspicion that the blocking issue will have fixed this as well, so I'm going to tag for manual testing. Can this still be reproduced?

Updating target branch to reflect where the former blocker was committed. That's where manual testing should happen to see if we can still reproduce this bug.

I tested this on Drupal 10.1.x, standard install. I tried to follow the steps the Issue Summary but I don't know what the last step means, "Select the translation to be based upon the row language [default setting]". I tried the steps in #4 and #18 and was not able to produce an error.

In order to continue here we need complete steps to reproduce the issue (starting from "Install Drupal core"). I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Since we need more information to move forward with this issue,and it has not been supplied in the past two years, I am closing this issue.

If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").

Thanks!

Not reopening without being sure of all steps to reproduce, but I ran into this on Drupal 10 with a paragraph relationship and a rendering language of "Content Language of View Row".

Possibly helpful context:
View is output in a block.
Avoiding this error by switching to a rendering language of entity default or applying a patch from here leads to warnings about fields on the referenced entity not existing.