Views caching causes validation error

[kswan]

Steps to recreate:

In a site with a few users create a user reference view that outputs some users. Set Caching to Time-based, 1 hour, 1 hour. Create a content type with a user reference field. On the user reference field set "View used to select the users" to the view created above. Add a node of the new content type and set the user reference field to "user a". Save the new node. Promptly edit the new node and change the user reference to "user b". You will see a validation error "User: this user can't be referenced."

Workaround

If we change the Caching to None, the validation error is gone and the field works as expected.

Factors

The function references_potential_references_view() sets $view->is_cacheable = FALSE, but this apparently isn't effective.

[jromine]

So if I'm understanding this right, you:

1. create a view that returns a list of some users
2. set the view to cache its results, time-based, 1hour
3. create a content type with a user reference field
4. configure the user reference field to use the user view as its allowed value list
5. create a node of the new content type with the user reference field value "user a"
6. edit the node, and attempt to change the user reference field value to "user b".
7. validation fails

Is "user b" in the result set from the view?

[kswan]

Yes. Both user a and user b are in the view. It also happens if you create a second node that references user b.

If you check the $results variable in references_potential_references_view() in references.module, you'll see that when validating step 6, the only result is the uid for user a.

By the way, I assume the caching issue would be the same for node references since the function building the view is the same, but I didn't test it.

[jromine]

The user reference field lists the users correctly, but the validation fails on node save.

Verified:

[jromine]

In the call to references_potential_references_view($entity_type, $view_name, $display_name, $args, $options), to render the select list, the $options is: and when validating the selection after clicking Save $options is: $options['ids'] = array('7') // 7 is the uid of the user I selected in the node edit form

In the first views query, the result set is an array of user uid's from the view, as expected. In the second views query, the result set is an array with only one element, the uid of the existing value of the references field (not 7, another uid). So that explains why the validation is failing, but not why the views query result is wrong.

[kswan]

If you flush the cache between the first (step 5) and second (step 6) validation, the result with one element will be the correct uid.

The validation also fails with different nodes that go through the validation within the cache window.

Also if you set caching in the view to none, the single element will be correct.

[jromine]

I am pretty confident this is a bug in views. The Drupal bug report is https://www.drupal.org/project/drupal/issues/1055616

Looking at the patch, it is updating get_results_key() and get_output_key(), and adding a new function get_cache_key(). I substituted the D7 versions of these functions in "views_plugin_cache.inc" and added get_cache_key() and the bug in this issue was fixed.

[jromine]

The Drupal patch is https://www.drupal.org/files/issues/views-1055616-152.patch (but note I only edited views_plugin_cache.inc as noted above).

[jromine]

Here is the Drupal commit: https://git.drupalcode.org/project/views/-/commit/0cb96e5269a5479498b6ca9f51762c68974923c8

[jromine]

@kswan you can file a bug report against Backdrop core views module at https://github.com/backdrop/backdrop-issues/issues/new/choose or if you prefer, I can do so for you. I don't think I am able to transfer this issue to the Backdrop core issue queue.

[jromine]

is_cacheable was removed from views. More info: https://www.drupal.org/project/views/issues/635336