See #2958587-19: Unable to filter on columns of entity reference fields.1:

+++ b/src/Context/FieldResolver.php
@@ -320,4 +352,93 @@ class FieldResolver {
+      $message = sprintf('Ambiguous path. Try one of the following: %s, before the given path: %s', $choices, $given);
+      throw new BadRequestHttpException($message);

There's no explicit test coverage for this yet.

And reply in #21:

There's no explicit test coverage for this yet. Having that would also help address #18.6.

Without a custom field type, this isn't possible to test. I'm happy to remove the logic, make a follow-up issue and hard-code the word entity in the method for now. What do you think? Add the robust logic now, without a test, or have a hardcoded value now with a follow-up and test?

We went with Add the robust logic now, without a test. This issue is for adding the test.

Comments

Wim Leers created an issue. See original summary.

wim leers’s picture

Assigned: Unassigned » gabesullice
wim leers’s picture

@gabesullice indicated in #2953207-32: Can't get the right target type when filtering on relationship with bundle-specific target entity type that this issue should also test that, and perhaps that's a use case that won't require a custom field type.

wim leers’s picture

Version: 8.x-1.x-dev » 8.x-2.x-dev
Assigned: gabesullice » Unassigned
Issue tags: +Needs tests
wim leers’s picture

Issue tags: +API-First Initiative

It'd be great to add test coverage for this before it goes into core.

wim leers’s picture

Title: Add explicit test coverage for ambiguous filter expression paths » Test coverage: ambiguous filter expression paths

Retitling to be consistent with other similar (test coverage) issues.

wim leers’s picture

The code quoted above that is in need of test coverage is now called less often as of #3010432: Filtering by referenced entity requires ".uuid" to be specified in filter path expression. That did add explicit tests. And that now explicitly does not call getDataReferencePropertyName() if there are no reference properties in existence; and we even have explicit test coverage that verifies you get useful errors: \Drupal\Tests\jsonapi\Kernel\Query\FilterTest::testInvalidFilterPathDueToNonexistentProperty(), \Drupal\Tests\jsonapi\Kernel\Query\FilterTest::testInvalidFilterPathDueToMissingPropertyNameReferenceFieldWithMetaProperties() and so on.

So this bit from #2958587-10: Unable to filter on columns of entity reference fields:

How does this fix things:
If the field is a reference, we now "peek" ahead to the next path part to see if it's actually a property of the reference field.

is now mitigated much more than it already was by #2958587 before.

But the test coverage advocated for here is still necessary, because it's specifically for the case where we have >=2 candidate fields to resolve a filter expression, >=1 where the DataReferenceDefinition property is named entity AND one where it is not named entity.
That is a fairly extreme edge case though, so demoting priority.

rpayanm’s picture

Project: JSON:API » Drupal core
Version: 8.x-2.x-dev » 8.9.x-dev
Component: Code » jsonapi.module

Moving to Drupal core's issue queue.

I'm working on https://www.drupal.org/project/drupal/issues/3122113

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.