Problem/Motivation

Lightning API is currently pins JSON API to 1.16. The latest release is 1.19.

Proposed resolution

Update to 1.19 and ensure tests pass

Comments

balsama created an issue. See original summary.

balsama’s picture

balsama
he/him
Primary language English
Location boston
commented

Updating to 1.19 caused the EntityCrudTest to fail while creating a new term via the api.

Interestingly, I was able to fix this by creating the term in the Tags vocabulary provided by standard instead of one created by the test.

Even more interesting, the test fails again if I add the creation of the test vocab back in even though I'm still creating the term in the preexisting Tags vocab.

Stack trace is the same for both failures:

/home/travis/build/acquia/lightning-api/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113
/home/travis/build/acquia/lightning-api/vendor/guzzlehttp/guzzle/src/Middleware.php:66
/home/travis/build/acquia/lightning-api/vendor/guzzlehttp/promises/src/Promise.php:203
/home/travis/build/acquia/lightning-api/vendor/guzzlehttp/promises/src/Promise.php:156
/home/travis/build/acquia/lightning-api/vendor/guzzlehttp/promises/src/TaskQueue.php:47
/home/travis/build/acquia/lightning-api/vendor/guzzlehttp/promises/src/Promise.php:246
/home/travis/build/acquia/lightning-api/vendor/guzzlehttp/promises/src/Promise.php:223
/home/travis/build/acquia/lightning-api/vendor/guzzlehttp/promises/src/Promise.php:267
/home/travis/build/acquia/lightning-api/vendor/guzzlehttp/promises/src/Promise.php:225
/home/travis/build/acquia/lightning-api/vendor/guzzlehttp/promises/src/Promise.php:62
/home/travis/build/acquia/lightning-api/vendor/guzzlehttp/guzzle/src/Client.php:131
/home/travis/build/acquia/lightning-api/vendor/guzzlehttp/guzzle/src/Client.php:89
/home/travis/build/acquia/lightning-api/docroot/modules/contrib/lightning_api/modules/api_test/tests/src/Functional/ApiTestBase.php:110
/home/travis/build/acquia/lightning-api/docroot/modules/contrib/lightning_api/modules/api_test/tests/src/Functional/EntityCrudTest.php:92

As well as the exception:

GuzzleHttp\Exception\ServerException: Server error: `POST http://127.0.0.1:8080/jsonapi/taxonomy_term/im_a_vocab` resulted in a `500 Internal Server Error` response:
{"errors":[{"title":"Internal Server Error","status":500,"detail":"Relationships to virtual resources are possible only  (truncated...)
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Assigned: Unassigned » wim leers
Issue tags: +API-First Initiative
Related issues: +#2940339: Port reference field support for non-empty entity reference fields not pointing to an entity from #2543726

Stack traces are utterly useless in functional PHPUnit tests, because they're the same for all of them: that's a stack trace for the test runner up to the point where it makes a HTTP request. Not where the code is failing.

GuzzleHttp\Exception\ServerException: Server error: `POST http://127.0.0.1:8080/jsonapi/taxonomy_term/im_a_vocab` resulted in a `500 Internal Server Error` response:
{"errors":[{"title":"Internal Server Error","status":500,"detail":"Relationships to virtual resources are possible only  (truncated...)

If you grep the code base for Relationships to virtual resources are possible, you'll find that this string was added in #2940339: Port reference field support for non-empty entity reference fields not pointing to an entity from #2543726, which indeed shipped with 1.19. I'll work on a regression test in JSON API, which should be able to either reproduce this (and result in an upstream bugfix), or it should result in me finding what was wrong in https://github.com/acquia/lightning-api/commit/f65e8bc0e67b44ad9d00287aa....

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Even more interesting, the test fails again if I add the creation of the test vocab back in even though I'm still creating the term in the preexisting Tags vocab.

This is most likely because in:

    if ($target_entity === NULL) {
      $host_entity = $parent->getHostEntity();
      $relatable_resource_types = $resource_type_repository->get(
        $host_entity->getEntityTypeId(),
        $host_entity->bundle()
      )->getRelatableResourceTypes()[$parent->getPropertyName()];
      if (count($relatable_resource_types) !== 1) {
        throw new \RuntimeException('Relationships to virtual resources are possible only if a single resource type is relatable.');
      }

Having multiple vocabularies causes $relatable_resource_types['parent'] to have multiple resource types.

FYI: I’ve just managed to reproduce it locally, without using Lightning API’s tests. So I’m on it. Expect a JSON API issue soon.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: Update to JSON API 1.19 » [PP-1] Update to JSON API 1.19
Assigned: wim leers » Unassigned
Status: Active » Postponed
Related issues: +#2977879: Regression in #2940339: when multiple vocabularies exist, normalization of Terms fails

Root cause found: bug in the Term entity type. Details at #2977879: Regression in #2940339: when multiple vocabularies exist, normalization of Terms fails.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#2977882: Term entity type's "parent" field does not specify "target_bundles" setting: a term from *any* vocabulary can be chosen

Now there is:

  1. a core patch to fix it at the root: #2977882: Term entity type's "parent" field does not specify "target_bundles" setting: a term from *any* vocabulary can be chosen
  2. a JSON API patch to patch core in JSON API while #2977882 waits to land: #2977879-5: Regression in #2940339: when multiple vocabularies exist, normalization of Terms fails
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#2980593: Follow-up for #2977879: remove work-around for #2977882

#2977882: Term entity type's "parent" field does not specify "target_bundles" setting: a term from *any* vocabulary can be chosen landed! So I created #2980593: Follow-up for #2977879: remove work-around for #2977882 to stop applying the work-around on 8.6.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: [PP-1] Update to JSON API 1.19 » Update to JSON API 1.20

BTW, https://www.drupal.org/project/jsonapi/releases/8.x-1.20 was released which includes the work-around. So was actually already unblocked for a while :)

balsama’s picture

balsama
he/him
Primary language English
Location boston
commented
Status: Postponed » Active

Thanks for this. This commit brought in the core patch referenced in #6 (bullet #1). We should remove that and update to 1.20 (which includes #6 (bullet #2).

  • d6f14c1 committed on 8.x-2.x 
    Issue #2977848 by Wim Leers, balsama: Update to JSON API 1.20
balsama’s picture

balsama
he/him
Primary language English
Location boston
commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

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