Problem/Motivation

The following error has been reported multiple times:

Argument 2 passed to Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}() must be an instance of Drupal\jsonapi\ResourceType\ResourceType, NULL given

The only potential source of this error is in Drupal\jsonapi\ResourceType\ResourceTypeRepository::getRelatableResourceTypesFromFieldDefinition():

    $has_target_bundles = isset($handler_settings['target_bundles']) && !empty($handler_settings['target_bundles']);
    $target_bundles = $has_target_bundles ?
      $handler_settings['target_bundles']
      : $this->getAllBundlesForEntityType($entity_type_id);

    return array_map(function ($target_bundle) use ($entity_type_id, $resource_types) {
      $type_name = "$entity_type_id--$target_bundle";
      return isset($resource_types[$type_name]) ? $resource_types[$type_name] : NULL;
    }, $target_bundles);

The two known reasons that NULL might be generated is if an entity reference field has handler settings referencing a missing target bundle or the resource type name has been overridden by JSON:API Extras.

Proposed resolution

Neither of these reasons is a bug in JSON:API, per se. Instead, they could be caused by bad configuration, a poorly defined custom base field, or by JSON:API Extras.

In order to help users suffering from those bugs, introduce exceptions that will pinpoint the source of the errors.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Release notes snippet

N/a

CommentFileSizeAuthor
#203 interdiff-124-201.txt1.66 KBsimohell
#203 interdiff-124-198.txt1.43 KBsimohell
#201 2996114-201.patch19.78 KBbsains
#200 2996114-100.patch19.78 KBbsains
#199 2996114-199.patch12.15 KBbsains
#198 2996114-198.patch19.76 KBsimohell
#190 2996114-190.patch14.92 KBjungle
#190 interdiff-186-190.txt754 bytesjungle
#186 interdiff-182-186.txt1.16 KBjungle
#186 2996114-186.patch14.89 KBjungle
#182 interdiff-80-82.txt606 bytesjungle
#182 2996114-82.patch15.2 KBjungle
#180 interdiff-179-180.txt304 bytesjungle
#180 2996114-180.patch15.19 KBjungle
#179 2996114-179.patch14.9 KBjungle
#179 interdiff-177-179.txt1.98 KBjungle
#177 interdiff-2996114-167-177.txt1.71 KBBR0kEN
#177 2996114-177.patch14.95 KBBR0kEN
#167 2996114-167.patch14.25 KBgabesullice
#167 2996114-167-test-only.patch10.29 KBgabesullice
#167 interdiff.txt19.47 KBgabesullice
#162 2996114-162.patch11.57 KBBR0kEN
#141 interdiff-2996114-124-141.txt513 bytesBR0kEN
#141 2996114-141.patch19.69 KBBR0kEN
#124 interdiff-2996114-123-124.txt3.16 KBBR0kEN
#124 2996114-124.patch19.7 KBBR0kEN
#123 interdiff-2996114-99-123.txt6.92 KBBR0kEN
#123 2996114-123.patch18.12 KBBR0kEN
#99 interdiff-2996114-97-99.txt745 bytesBR0kEN
#99 2996114-99.patch12.45 KBBR0kEN
#97 2996114-97.patch12.1 KBBR0kEN
#97 2996114-97-do-not-commit.patch6.04 KBBR0kEN
#93 2996114-93.patch10.13 KBBR0kEN
#93 2996114-93-do-not-commit.patch5.7 KBBR0kEN
#90 2996114-90.patch4.43 KBBR0kEN
#90 interdiff-2996114-89-90.patch2.25 KBBR0kEN
#89 2996114-89.patch3 KBBR0kEN
#87 Screenshot 2019-12-02 at 19.07.59.png606.11 KBBR0kEN
#85 class_instance_issue-2996114-85.patch1.59 KBnishantkumar155
#69 good point.png635.06 KBlawxen
#68 2996114-68.patch4.25 KBgabesullice
#68 interdiff-67-68.txt1.45 KBgabesullice
#67 2996114-67.patch4 KBgabesullice
#67 interdiff-48-67.txt2.21 KBgabesullice
#48 2996114-48.patch3.27 KBgabesullice
#48 2996114-48--test-only.patch1.45 KBgabesullice
#48 interdiff.txt1.23 KBgabesullice
#44 2996114-44.patch1.79 KBgabesullice
#42 2996114-42.patch1.79 KBgabesullice
#31 jsonapi_routes_config_catching.patch5.05 KBtengoku
#17 jsonapi_2996114.patch1.47 KBtengoku
#16 class_instance_issue-2996114-16.patch1.34 KBARUN AK
#13 null-given-2996114-13.patch1.48 KBjungle
#9 class_instance_issue-2996114-9.patch1.39 KBARUN AK
#5 2996114-5-debug-do-not-test.patch772 bytesWim Leers

Issue fork drupal-2996114

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

caseylau created an issue. See original summary.

lawxen’s picture

Status: Active » Closed (won't fix)

Reproduced steps:

  1. Install commerce_order and jsonapi:2.x-dev
  2. Remove all profile bundle.
  3. drush cr

The commerce_order's billing_profile filed reference profile-customer, but the profile bundle:customer has been deleted by us, so the error come.
But I don't think we need spend time on it.

Wim Leers’s picture

Status: Closed (won't fix) » Closed (works as designed)
SocialNicheGuru’s picture

Status: Closed (works as designed) » Active

How did you find what was deleted?

I am trying to debug and I cannot find what was deleted or not to make this happen.

I think there should be a check placed in here that will at least write to logs what is passing in a NULL resource

Wim Leers’s picture

Category: Bug report » Support request
Status: Active » Fixed
Issue tags: +API-First Initiative
FileSize
772 bytes

@SocialNicheGuru This debug patch should help you figure it out :)

SocialNicheGuru’s picture

Thanks for this.

drush pm-uninstall jsonapi

The following extensions will be uninstalled: entity_share, entity_share_client, entity_share_server

Do you really want to continue? (y/n): y
array(1) {
["tags"]=>
NULL
}

I had to add a vocab called 'tags'.

Status: Fixed » Closed (fixed)

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

ARUN AK’s picture

I am also facing the same issue after upgrade into the latest version.

ARUN AK’s picture

Can we add a check here to avoid this error?

malks’s picture

Is there anything more refined suggested to find the missing bundle? We have a complex site where a clean install doesn't work... I put the debug patch in place and so far the var_dump is 6.1G :/. I've tried running this under breakpoint debugging but I can't seem to get it to hit the right place to inspect variables. Any better ideas or a way to make this more robust?

malks’s picture

Actually, the snippet below just before the call to array_reduce pinpointed it for me. Given that it's just trying to remove invalid route candidates this should just silently move on to the next target as the previous commenter suggested?

foreach ($resource_types as $key => $value) {
      if ($value === NULL) {
        print "Empty related resource " . $key . "\n";
      }
    }
jungle’s picture

Project: JSON:API » Drupal core
Version: 8.x-2.x-dev » 8.7.x-dev
Component: Code » jsonapi.module
Assigned: Unassigned » jungle
Category: Support request » Bug report
Priority: Normal » Major

Reproduced, when upgrading Drupal core to 8.7.0-beta1, Move it to Drupal core,

jungle’s picture

FileSize
1.48 KB

Fixed the error, and using foreach, instead of array_reduce, to return early if possible.

jungle’s picture

Hi @ARUN AK

+++ b/src/Routing/Routes.php
@@ -432,9 +432,11 @@ class Routes implements ContainerInjectionInterface {
+        return $carry || !$target->isInternal();

Can not add type hint `ResourceType` to the 2nd argument here, it could be null, null is not an instance of ResourceType, that's why it throws errors.

Simply remove the type hint, your patch works.

jungle’s picture

Assigned: jungle » Unassigned
ARUN AK’s picture

I have combined the changes from @jungle's patch and made it work with 8.6.x.

tengoku’s picture

Hi All.. i'm uploading this to re-roll the patch for drupal core on 8.7.2, since the patch posted here looks like is for the contributed module and not the core one.

thanks!

egruel’s picture

The patch in #17 Work for me on drupal 8.7.2
This issue need to be reopen.

grahl’s picture

Can reproduce this when installing a site from configuration as well with 8.7.2, patch #17 resolves it.

+1 on reopen (or creating a new issue if the maintainer isn't watching here).

bdlangton’s picture

Patch #17 resolves the issue for me as well, and I agree with re-opening.

kyletaylored’s picture

Had the same issue, #17 worked for me against 8.7.3.

nielsaers’s picture

Same here, #17 worked for me against 8.7.2

mikemadison’s picture

it looks like this issue auto-closed without activity and didn't get merged in, can we get it reopened?

tim.plunkett’s picture

Status: Closed (fixed) » Active
lcatlett’s picture

The patch in #17 resolves this issue for me against 8.7.3

gnikolovski’s picture

Status: Active » Needs review

Patch #17 resolves this issue for me.

bradjones1’s picture

Title: Argument 2 passed to Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}() must be an instance of Drupal\jsonapi\ResourceType\ResourceType, null given » jsonapi exception when installing from configuration
Wim Leers’s picture

Title: jsonapi exception when installing from configuration » Detect invalid entity reference field configuration and provide an actionable error
Category: Bug report » Task
Status: Needs review » Needs work
Issue tags: +Entity Field API, +Configuration system, +Configuration schema, +validation, +DX (Developer Experience), +Needs tests

Committing #17 would be accepting broken configuration. That'd be wrong.

We need to refactor #5 to detect the problem and provide an actionable error response.

Wim Leers’s picture

The number of people with invalid configuration is frightening by the way 😨

Wim Leers’s picture

Title: Detect invalid entity reference field configuration and provide an actionable error » Detect invalid entity reference field configuration (pointing to non-existing bundles) and provide an actionable error
tengoku’s picture

Hi All... based on #29 comment, then i wrote this debug patch. instead of using the function the triggered the error, i put a try/catch code on the parent functions. Showing the entity and the path affected.

Instead of breaking the site, this just send an error message (this error is only trigger on clearing cache - on my experience - ).

For testing it, I did a clean install and just enabling the modules, later a config export/import.. and my error(s) is this one.

JSONAPI: Fatal error looking internal resource types on entity commerce_payment_method, bundle credit_card, field billing_profile and path /commerce_payment_method/credit_card
JSONAPI: Fatal error looking internal file target resource types on entity commerce_payment_method, carry credit_card and path /commerce_payment_method/credit_card
JSONAPI: Fatal error looking internal resource types on entity commerce_payment_method, bundle paypal, field billing_profile and path /commerce_payment_method/paypal
JSONAPI: Fatal error looking internal file target resource types on entity commerce_payment_method, carry paypal and path /commerce_payment_method/paypal

Now, i'm just an ignorant on the error, what this means and what i have to check? at least i know is the commerce_payment_method module that is giving me problems

ivan.chavarro’s picture

Hi everyone, the patch #31 solves the issue, the errors are displayed before you run drush cim, but after they go away.

gabesullice’s picture

Title: Detect invalid entity reference field configuration (pointing to non-existing bundles) and provide an actionable error » Argument 2 passed to Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}() must be an instance of Drupal\jsonapi\ResourceType\ResourceType, NULL given

I think I found a legitimate source of this bug (without invalid configuration). I described that problem in #3034786-37: ResourceIdentifier::getVirtualOrMissingResourceIdentifier() ignores field aliases; causes $relatable_resource_types field to be empty and results in an error. Transcribing here:

Finally, while mentally stepping through the code, I found another bug ... . getRelatableResourceTypesFromFieldDefinition returns the result of:

return array_map(function ($target_bundle) use ($entity_type_id, $resource_types) {
  $type_name = "$entity_type_id--$target_bundle";
  return isset($resource_types[$type_name]) ? $resource_types[$type_name] : NULL;
}, $target_bundles);

Notice that $type_name is constructed by concatenating the entity type ID with the bundle ID. However, $resource_types is created with:

return array_merge($resource_types, [
  $resource_type->getTypeName() => $resource_type,
]);

Meaning if the resource type name has been aliased, we'll have NULL values in the relatable resource type array and nothing to filter those out.

Restoring the original title since it's now clear that the problem is bigger than the prescribed solution.

joachim’s picture

The issue summary needs an update, as I can't really tell what this issue's proposed resolution is.

This former title looks like one possibility, for instance:

> Detect invalid entity reference field configuration (pointing to non-existing bundles) and provide an actionable error

joachim’s picture

+++ b/core/modules/jsonapi/src/Routing/Routes.php
@@ -215,9 +217,21 @@ protected static function getFileUploadRoutesForResourceType(ResourceType $resou
+    try {
+      $has_file_field = FALSE;
+      $has_file_field = array_reduce($resource_type->getRelatableResourceTypes(), function ($carry, array $target_resource_types) {
+        return $carry || static::hasNonInternalFileTargetResourceTypes($target_resource_types);
+      }, FALSE);
+    }
+    catch (TypeError $e) {

Catching a TypeError seems like a pretty hacky way to do this. Code should be checking we get something legitimate earlier on rather than having PHP complain.

nishantkumar155’s picture

Hello drupaler ,

I have just applied patch #31 it not worked for me for 8.7.7

penyaskito’s picture

Had this same problem myself, #17 fixed it for me.

In my case, the problem happened with a custom module adding an entity reference to commerce_order in hook_entity_base_field_info:

      ->setSetting('handler_settings', ['target_bundles' => ['a_node_type_in_config' => 'a_node_type_in_config']])

If I removed that line, it worked. With #17, it works.

danrod’s picture

Patch #16 Works for me (Running 8.6.x), thanks a lot @ARUN_AK for your work on this, I am having huge issues with this JSON API module (which I'm planning to uninstall in the near future), and this patch is a temporary fix for me.

mglaman’s picture

#37, @penyaskito so we might be able to reproduce by adding an entity reference base field via hook_entity_base_field_info to a test entity against a node type, with handler_settings and target_bundles defined?

I think one step is to get a failing test.

saltednut’s picture

The number of people with invalid configuration is frightening by the way

The site builders among us often have no idea when or why these things happen and its typically contrib modules that lead to this. We shouldn't judge too harshly... 😇

Re: #35 - Is there something that we can try to do to inform users without compromising the integrity of the API via hacks?

For what its worth, I can confirm that the patch from #31 obfuscated the error we were seeing during installation, but I'm still at a loss for what configuration in my system was/is invalid. I don't see anything in the logs about it after applying the patch even after re-installing everything from our profile down to the module that included jsonapi.

While it isn't the job of jsonapi to be pointing these things out, it probably IS the job of core to disallow invalid configuration to be installed. We shouldn't be getting down to a level with jsonapi failing during install due to invalid config already installed. However, its better to find/discover this stuff via jsonapi install than it would be during production. Unfortunately, it looks like at this time, all we are able to do is gracefully walk around the error while remaining ignorant as to what the original source is.

gabesullice’s picture

Hi everyone! Thank you all for your help and interest on this issue! I see that this issue has 36 followers, so I presume there are at least that many people on the internet that are experiencing a similar error. Unfortunately, the patches provided cannot be committed because I do not feel comfortable with them and we don't yet have a "complete" issue for a core commit. Why?

  1. We do not have steps to reproduce the error
  2. We do not have tests that prove the error and the fix
  3. The existing fix is really covering up a symptom, not addressing the cause (because we don't know what that is)

We need a reset.

In #33, I detailed one possible source of the error. I propose that we write a test that proves that bug, then write a patch that fixes it, then commit it.

I suspect that it will resolve at least some of the errors that the followers of this issue are experiencing.

I also suspect that it will not resolve it for others. If you are one of the followers of this issue and that committed patch does not solve your error, we really need you to spend the time to provide steps to reproduce your error and share them with us so that we can write a test and a fix for your issue. Your help will be tremendously appreciated! AND, you'll get contribution credit!

gabesullice’s picture

Version: 8.7.x-dev » 8.9.x-dev
Status: Needs work » Needs review
FileSize
1.79 KB

ignore

gabesullice’s picture

Issue summary: View changes
Issue tags: -Needs tests, -Needs issue summary update
+++ b/core/modules/jsonapi/src/ResourceType/ResourceTypeRepository.php
@@ -464,14 +464,23 @@ protected function getRelatableResourceTypesFromFieldDefinition(FieldDefinitionI
+        throw new \LogicException("A resource with the type name $type_name does not exist.");

Nit: "A resource type with the name $type_name does not exist."

gabesullice’s picture

This patch should help anyone identify the source of this error. It does not provide a fix on its own because the exceptions that are thrown must either be a result of bad configuration, a module defining a bad base field, or JSON:API Extras.

Please apply this patch, test it, and report the results! If the patch helped you find and fix the source of your problem, we would still like to know, so thank you for reporting that in advance 🙏

effulgentsia’s picture

For adding test coverage to #44, I think we can follow the lead of #37, and do something like:

function test_entity_base_field_info(EntityTypeInterface $entity_type) {
  if ($entity_type->id() === 'user') {
    $fields['favorite_article'] = BaseFieldDefinition::create('entity_reference')
      ->setLabel(t('Favorite article'))
      ->setSetting('target_type', 'node')
      ->setSetting('handler_settings', ['target_bundles' => ['article']]);

    return $fields;
  }
}

Except maybe using test entity types instead of users and nodes. But I can confirm that if I manually enable the above module on my machine, and delete the Article content type, then when I clear caches, in HEAD I get the same error that's in the issue summary, and with #44 I get the new exception.

effulgentsia’s picture

We might want to open a separate issue to throw an exception in EntityFieldManager or EntityReferenceItem when encountering #45.

Status: Needs review » Needs work

The last submitted patch, 44: 2996114-44.patch, failed testing. View results

gabesullice’s picture

Status: Needs work » Needs review
FileSize
1.23 KB
1.45 KB
3.27 KB

The #47 failure was just a testbot thing. I retested #44 and it came back green.

Anyway, here's something similar to @effulgentsia's suggestion in #45. Indeed, the test only patch gives the reported error. The complete patch should give one of the new LogicExceptions. The interdiff is just me cleaning up and rewording that exception.

The last submitted patch, 48: 2996114-48--test-only.patch, failed testing. View results

mglaman’s picture

Chiming in that I have found a way to immediately reproduce this using Drupal Commerce 2.14

I have JSON:API module installed. I then installed commerce, commerce_order, commerce_price, commerce_store and then 💥

[Wed Oct 30 10:59:56 2019] TypeError: Argument 2 passed to Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}() must be an instance of Drupal\jsonapi\ResourceType\ResourceType, null given in /web/core/modules/jsonapi/src/Routing/Routes.php on line 434 #0 [internal function]: Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}(false, NULL)

I haven't determined if it's due solely to base fields or field config.

---

When Commerce is installed first, everything is OK. I think that is due to the fact we install an entity reference field config definition on installation.

This is fixed in Commerce on #3002939: Convert order/product multivalue configurable fields back into base fields.

So it seems to only affect field config definitions. Given: https://git.drupalcode.org/project/commerce/blob/8.x-2.x/modules/order/c..., there is to target bundles.

gabesullice’s picture

@mglaman, the patch in #48 adds more informative exceptions that should be useful to you. They should point you in the right direction. Since you now have reproduction steps, if #48 helps you find the root cause of the bug in Commerce, then I think it'd be safe to RTBC this issue. If you find out that the bug is still present and the exception is unhelpful, understanding why would move this issue forward even further :)

penyaskito’s picture

@gabesullice @mglaman Sorry I couldn't get back to this yet. #50 may actually explain my issue, as I was using the said modules. I'll try the commerce patch explained at #50, if the error disappears for me there's no need to write the test described at #37 as it won't be JSON:API fault.

mglaman’s picture

Status: Needs review » Reviewed & tested by the community

🙌this patch helps isolate the error, which makes for a much nicer developer experience over the cryptic generic message.

  Invalid field settings detected. The `billing_profile` field on the `commerce_payment_method` entity type has one or more missing target bundles: `customer`  

Unrelated to this issue, it is uncovering a weird problem on install. The profile type bundle "customer" is not being recognized, even though a dependency installed it.

web/core/lib/Drupal/Core/ProxyClass/Routing/RouteBuilder.php(83): Drupal\Core\Routing\RouteBuilder->rebuild()
web/core/lib/Drupal/Core/Extension/ModuleInstaller.php(342): Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild()
web/core/lib/Drupal/Core/ProxyClass/Extension/ModuleInstaller.php(83): Drupal\Core\Extension\ModuleInstaller->install(Array, false)
web/core/lib/Drupal/Core/Config/ConfigImporter.php(813): Drupal\Core\ProxyClass\Extension\ModuleInstaller->install(Array, false)
web/core/lib/Drupal/Core/Config/ConfigImporter.php(577): Drupal\Core\Config\ConfigImporter->processExtension('module', 'install', 'commerce_paymen...')

:/ or it's due to this all running from ConfigImporterBatch


So it seems like this bug could occur if routes are rebuilt before config sync is finished and bundles are installed completely.


Final edit. When I applied #3086307: Improve installer performance by ~20% by rebuilding the router after the entire installation is complete rather than after each module the problem fixed itself. JSON:API routes are rebuilt too often while the system is in flux and not in a stable state.

larowlan’s picture

+++ b/core/modules/jsonapi/src/ResourceType/ResourceTypeRepository.php
@@ -464,14 +464,25 @@ protected function getRelatableResourceTypesFromFieldDefinition(FieldDefinitionI
+      throw new \LogicException($message);
...
+        throw new \LogicException("A resource type with the name $type_name does not exist.");

Are we sure an exception is the best way to handle these - i.e. can we not just log the missing bundles and remove them?

Whilst an exception is more helpful than the current state, it still results in a 500 error that a site builder may be unable to resolve.

mglaman’s picture

Whilst an exception is more helpful than the current state, it still results in a 500 error that a site builder may be unable to resolve.

Would a site builder then know there's a problem? How would we bubble it up? With silent logging to the database I wouldn't know there was an edge case error with my route compilation

The real bug is Drupal not ensuring the setting exists on the field config definition.

larowlan’s picture

Views just logs an error in a similar scenario

gabesullice’s picture

@larwolan, these exception are only thrown during a router rebuild and only after a config change or a module install. I think this will appear during a development phase when it's clear what needs to happen.

FWIW, I'm not aware of any other place where JSON:API logs errors to the watchdog. Everything either fails during dev or results in HTTP error responses.

gabesullice’s picture

Wait, I think I see what you're saying now. If a site builder enables the module or somehow breaks config, they're gonna be stuck with a WSOD from this exception and won't be unable to fix the problem. Let me do some digging to confirm whether that's actually the case. I'd like to avoid watchdog if at all possible. That's where errors go to die.

bradjones1’s picture

I'd like to avoid watchdog if at all possible. That's where errors go to die.

🔥️

ndobromirov’s picture

I've tested the patch in #48 by manually porting it to the current contrib 2.x version for the module.

The error I am experience in #3089393: Exception in JSON:API fetching content. is not resolved with the patch from #48. I am still getting the same exception and not the new one as introduced here.

Note that the patch in the referenced issue solved it for now. Should it get incorporated here or I should reopen the other issue?

gabesullice’s picture

@ndobromirov, I think you should reopen the other issue since you're testing with 2.x contrib JSON:API, not core's JSON:API. Perhaps something has diverged.

Wim Leers’s picture

#41++

#50 and #53 confirm the value of this patch :)

Morbus Iff’s picture

I've running into the same "Argument 2" error after adding jsonapi and jsonapi_extras to my installation profile in an 8.7.x site. Using a modified version of #48, I receive "A resource type with the name contact_form--contact_form does not exist." My installation profile does require the contact module, as well as provides configuration in config/contact.form.feedback.yml and config/contact.settings.yml. This particular break was a bit surprising to me, though, as I was expecting to see the same thing as mglaman, as this installation profile also installs commerce and all the fixins.

Unlike mglaman's comment in #53, however, an 8.7.x version of #3086307: Improve installer performance by ~20% by rebuilding the router after the entire installation is complete rather than after each module didn't help - the same Argument 2 error occurs. In this particular case, the installation died with "A resource type with the name block_content_type--block_content_type does not exist."

I also haven't had any luck with moving the installation of jsonapi to "later" in the install profile. My profile has two module installation points - the standard one that happens via .info.yml (which I use for all core and contrib modules) and then a second one, as a custom install task later (which is used for all custom modules). Moving jsonapi to the second custom install task results in "A resource type with the name block_content_type--block_content_type does not exist."

Sadly, #17 is the only patch that seems to work for me so far. It allows me to enable jsonapi and jsonapi_extras in the profile's .info.yml, allows me to ship content/jsonapi*.settings.yml in the profile, and everything "seems" to work so far. #17 "accepts" the missing (as opposed to broken) configuration that occurs at installation time in between all the dependencies, refreshing, rebuilding, etc., etc.

gabesullice’s picture

AFAICT, the exception A resource type with the name contact_form--contact_form does not exist. can only be encountered when JSON:API Extras has changed the resource type name. For example, maybe you have renamed contact_form--contact_form to contactForm (or something else)? If that's the case, can you either try removing those renames or disabling JSON:API Extras? If that fixes it, then we should open a bug report for your problem in the JSON:API Extras issue queue.

Morbus Iff’s picture

@gabesullice: Retested. With *just* jsonapi in my 8.7.8's installation profile (no jsonapi_extras, no config/install/jsonapi.settings.yml), I receive "A resource type with the name contact_form--contact_form does not exist.".

gabesullice’s picture

Status: Reviewed & tested by the community » Needs work

Thanks for doing the extra testing @Morbus Iff! I think it's clear that there's an unmet config dependency problem then. Let me try to adjust #48 to give us even more clarity.

gabesullice’s picture

Status: Needs work » Needs review
FileSize
2.21 KB
4 KB

I'm really quite stumped. This is an enhancement to #48. Hopefully it'll help us narrow down source of the problems even further.

gabesullice’s picture

lawxen’s picture

FileSize
635.06 KB

One year ago this is a suffer problem when I create this issue.

I'm writing Drupal code just now, and I met this crash error again when clear the cache in other project.

After investigate, I found this crash "help me a great favor". I like this crash.

Below image is my code.
I create a group content plugin for entity type: pipeline, but in the GroupPipelineDeriver I didn't change the ProductType to PipelineType when copy code from other place. In my project ProductType and PipelineType has same bundle names.

So if there's no jsonapi, no this crash, I won't find this error until several months or several years has past, but after so long time, I guess the system's data has been in chaos.

So just give more detailed crash info(later patch) may be better than make the error disappear(earlier patch).

gabesullice’s picture

👋 hi @lawxen! It's good to see you in the issue queue again! I'm glad that the new patch helped you find a problem :D That's what it was for.

gabesullice’s picture

I just had a very productive debugging session with @Morbus Iff in Slack.

We finally found out the source of the issue and why I was so stumped in #67.

Drupal 8.7 is broken and will not be fixed because the release cycle for 8.7 has ended. The solution is to upgrade to 8.8 or above.

If you are on Drupal 8.8 or above and you are still getting an error, then please apply #68. Just like @mglaman and @lawxen have confirmed, it will be very useful for finding the root cause of the error outside of JSON:API. Like @lawxen said, it is better to fix your site rather than ignore the underlying problem (which is what #17 does).

For background, the reason that 8.7 is broken but 8.8 is not is because #3018287: ResourceTypeRepository computes ResourceType value objects on *every request* unknowingly fixed one source of the now infamous Argument 2 error. Since #3018287 was a performance enhancement, it was not backported to 8.7.

Since I have been looking exclusively at the 8.8 and 8.9 branches, I could not understand why @Morbus Iff and others were having so many problems.

So, the solution is to upgrade to 8.8. If you are still having issues after upgrading to Drupal core 8.8, apply the latest patch on this issue. The exceptions should help you identify the source(s) of the problems in your sites custom/contrib modules or in Drupal core itself. If you find them, please post back here and open separate issues to fix them. I also believe that #3086307: Improve installer performance by ~20% by rebuilding the router after the entire installation is complete rather than after each module should be very useful for working around configuration dependency issues.

gabesullice’s picture

Giving credit to @Mobus Iff

gabesullice’s picture

Version: 8.9.x-dev » 8.7.x-dev
Category: Task » Support request
Status: Needs review » Fixed

See #71 for details about how you can find and fix the source of the Argument 2 passed to... error, if you're encountering it.

lawxen’s picture

@gabesullice Really thanks for your patch, I indeed disappeared for a long time, haha. But I found some weird thing: "The crash not always happen when system has same problem" , maybe some other deeper problems is in drupal core, so reported it out.

Steps:
Environment: Drupal 8.8.x-dev, group:1.x-dev

  1. I use yesterday's database, and first add these wrong code, then install these plugin in group config page.
  2. Clear the cache
    PHP Fatal error:  Uncaught TypeError: Argument 2 passed to Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}() must be an instance of Drupal\jsonapi\ResourceType\ResourceType, null given in /Users/xyz/Documents/app/drupal/tla/web/core/modules/jsonapi/src/Routing/Routes.php:434
    Stack trace:
    #0 [internal function]: Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}(false, NULL)
    #1 /Users/xyz/Documents/app/drupal/tla/web/core/modules/jsonapi/src/Routing/Routes.php(436): array_reduce(Array, Object(Closure), false)
    #2 /Users/xyz/Documents/app/drupal/tla/web/core/modules/jsonapi/src/Routing/Routes.php(339): Drupal\jsonapi\Routing\Routes::hasNonInternalTargetResourceTypes(Array)
    #3 /Users/xyz/Documents/app/drupal/tla/web/core/modules/jsonapi/src/Routing/Routes.php(183): Drupal\jsonapi\Routing\Routes::getIndividualRoutesForResourceType(Object(Drupal\jsonapi\ResourceType\ResourceType))
    #4 /Users/xyz/Documents/app/drupal/tla/web/core/modules/jsonapi/src/Routing/Routes.php(116): Drupal\jsonapi\Routing\Routes::g in /Users/xyz/Documents/app/drupal/tla/web/core/modules/jsonapi/src/Routing/Routes.php on line 434
    
    Fatal error: Uncaught TypeError: Argument 2 passed to Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}() must be an instance of Drupal\jsonapi\ResourceType\ResourceType, null given in /Users/xyz/Documents/app/drupal/tla/web/core/modules/jsonapi/src/Routing/Routes.php:434
    Stack trace:
    #0 [internal function]: Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}(false, NULL)
    #1 /Users/xyz/Documents/app/drupal/tla/web/core/modules/jsonapi/src/Routing/Routes.php(436): array_reduce(Array, Object(Closure), false)
    #2 /Users/xyz/Documents/app/drupal/tla/web/core/modules/jsonapi/src/Routing/Routes.php(339): Drupal\jsonapi\Routing\Routes::hasNonInternalTargetResourceTypes(Array)
    #3 /Users/xyz/Documents/app/drupal/tla/web/core/modules/jsonapi/src/Routing/Routes.php(183): Drupal\jsonapi\Routing\Routes::getIndividualRoutesForResourceType(Object(Drupal\jsonapi\Resource [warning] Drush command terminated abnormally. Check for an exit() in your Drupal site.
    Type\ResourceType))
    #4 /Users/xyz/Documents/app/drupal/tla/web/core/modules/jsonapi/src/Routing/Routes.php(116): Drupal\jsonapi\Routing\Routes::g in /Users/xyz/Documents/app/drupal/tla/web/core/modules/jsonapi/src/Routing/Routes.php on line 434
    
  3. Apply the patch of #68, then execute drush cr
    In ResourceTypeRepository.php line 487:
                                                                                                                                                   
      Invalid field settings detected. The `entity_id` field on the `group_content` entity type has one or more missing target bundles: `project` 
  4. Fix my code, change ProductType to PipelineType, execute drush cr, no error appeared again.
  5. (key step)Then:
    Uninstall these group content plugin in group config page. then execute drush cr, then change my code to the bad version of step 1. install these plugin in group config page again, execute drush cr, no error appeared
  6. Don't change code, use yesterday's datdabase again to test, install these group content plugin in group config page, drush cr, crash apeared again

It seems that drupal core stores some route info into the database and didn't change when redo sth......

lawxen’s picture

Category: Support request » Bug report

@gabesullice Suggest that #68 be committed to drupal core, or it's confused when people met this incomprehensible crash after enable jsonapi.
#68 make people think that Drupal is robust💪, it's not a buggy system🐛.

So I reopen this issue. feel free to close it again 😁

lawxen’s picture

Status: Fixed » Needs review
lawxen’s picture

Status: Needs review » Reviewed & tested by the community
gabesullice’s picture

Fair enough @lawxen. The reason I changed it to a support request and marked it "Fixed" is because the issue really isn't really a bug in JSON:API. I guess we could make this issue a "Task" again.

I'm not really interested in converting the exceptions into log messages like @larowlan suggested in #54 and #56. Maybe there's another approach or maybe we can simply make the case that exceptions are really the best choice.

I'm curious what @Wim Leers thinks. I pinged him on Slack.

Wim Leers’s picture

The only other case of using logging in JSON:API is \Drupal\jsonapi\EventSubscriber\ResourceResponseValidator::validateSchema().

Everywhere else, we throw \LogicExceptions. For example:

throw new \LogicException("Only content and config entity types are supported.");

which is also an explicit data modeling issue, just like this.

Generally speaking, we throw exceptions when there is no way that we can deliver a sensible response. That's the case here. If we'd remove the missing bundles like @larowlan suggests, other data integrity problems may arise, and JSON:API should not allow for that.

gabesullice’s picture

@Wim Leers, I should have also pointed you to #58 when I asked for your opinion. It was poorly written, but the gist is that if a site builder goes to the "Extend" page and enables JSON:API and they have a pre-existing fault in their Drupal site that would trigger our exception then they're going to get a WSOD after enabling JSON:API. Since the exception will be thrown during a router rebuild, I don't think they'll be able to get back to the "Uninstall" page where they could remove JSON:API (since no routes will exist).

Just writing this out, I had the idea that we could wrap the code in Drupal\jsonapi\Routing\Routes::routes() with a try/catch block. If we catch an exception, we won't generate any JSON:API routes. In that case, we could somehow get the exception into the face of the user. Mabe via drupal_set_message or w/e it is now.

Wim Leers’s picture

#80 sounds sensible. I think that means this patch needs work though?

gabesullice’s picture

Version: 8.7.x-dev » 8.9.x-dev
Category: Bug report » Task
Status: Reviewed & tested by the community » Needs work

Yep.

gabesullice’s picture

So, to summarize what this patch needs:

  1. We should validate that throwing an exception in Drupal\jsonapi\Routing::routes() causes an unrecoverable WSOD if you install JSON:API (this can be manually validated by just modifying the code and trying it locally)
  2. If that assumption is true ^, a try/catch block should be added in Drupal\jsonapi\Routing::routes() and should be surfaced to the user without causing a WSOD. Ideally, that message will appear whether you enable JSON:API in the admin UI or via drush

Volunteers needed ;)

Morbus Iff’s picture

Sadly, I've been working on upgrading to 8.8.0-beta1 today, and can confirm that "out of the box", 8.8.0 does not fix this error that plagued me in 8.7.x (see #63 and the outcome #71). I'll have to apply the diagnostic patch (#68) again and see what I can see :(

nishantkumar155’s picture

Hi All.. i'm uploading #17 patch for drupal core on 8.7.10, since the patch posted here looks like there is line no change

thanks!

Status: Needs review » Needs work

The last submitted patch, 85: class_instance_issue-2996114-85.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

BR0kEN’s picture


Is this how it supposed to be?

BR0kEN’s picture

TBH, it takes some extra time to understand this code. Not a quick read.

    if (!isset($this->relatableResourceTypesByField)) {
      $this->relatableResourceTypesByField = array_reduce(array_map(function (ResourceTypeRelationship $field) {
        return [$field->getPublicName() => $field->getRelatableResourceTypes()];
      }, array_filter($this->fields, function (ResourceTypeField $field) {
        return $field instanceof ResourceTypeRelationship;
      })), 'array_merge', []);
    }
BR0kEN’s picture

Status: Needs work » Needs review
FileSize
3 KB

Here's another point of view on this issue. I think we should use internal resource names under the hood all the time and expose their renamed versions only to the clients (and decode as early as possible to internal ones when a request comes to the backend (POST, PATCH, etc)).

BR0kEN’s picture

A slightly different version that allows further use of getTypeNameInternal().

My bad: forgot the *.txt extension for the interdiff.

BR0kEN’s picture

Morbus Iff’s picture

Coming back to this after a vacation. To recap: out of the box (no JSON:API patches), 8.8.0-rc1 does not fix the error that plagued me in 8.7.x (see #63 and the outcome #71). This morning, I applied patch #68 to provide more analysis of the issue, and it dies with an error against Commerce 2.15: "Invalid field settings detected. The `billing_profile` field on the `commerce_order` entity type has one or more missing target bundles: `customer`".

This is the same error reported in #53 by @mglaman, however, applying #3076307.12 DOES NOT improve things. Profile installation still dies with the same error.

BR0kEN’s picture

- The patch that proves the error exists when the typeName is modified (as JSON:API Extras does).
- The patch that provides the fix.

BR0kEN’s picture

However, this fix is pure garbage in core as we satisfy the JSON:API Extras only. I'm thinking about deprecating the ability to modify typeName in Drupal\jsonapi_extras\ResourceType\ConfigurableResourceType::setJsonapiResourceConfig().

BR0kEN’s picture

... and my patch breaks paramconverter.jsonapi.resource_type.

The last submitted patch, 93: 2996114-93-do-not-commit.patch, failed testing. View results

BR0kEN’s picture

This one seems better as it allows using both internal and renamed ID of a resource type.

Status: Needs review » Needs work

The last submitted patch, 97: 2996114-97.patch, failed testing. View results

BR0kEN’s picture

Status: Needs work » Needs review
FileSize
12.45 KB
745 bytes

The last submitted patch, 97: 2996114-97-do-not-commit.patch, failed testing. View results

Morbus Iff’s picture

I believe I've got a reproducible, smaller, use-case for this issue.

  1. Run drupal-8.8.0-rc1.
  2. composer require "drupal/admin_toolbar"
  3. composer require "drupal/commerce"
  4. Modify core/profiles/demo_umami/demo_umami.info.yml file to include the following after the content_translation dependency:
      - drupal:jsonapi
      - admin_toolbar:admin_toolbar
      - admin_toolbar:admin_toolbar_tools
      - admin_toolbar:admin_toolbar_links_access_filter
      - commerce:commerce
      - commerce:commerce_cart
      - commerce:commerce_checkout
      - commerce:commerce_log
      - commerce:commerce_order
      - commerce:commerce_payment
      - commerce:commerce_price
      - commerce:commerce_product
      - commerce:commerce_store
    
  5. Run drush -y site-install demo_umami --db-url="sqlite://localhost//tmp/site.sqlite" --account-name="admin" --account-pass="admin" --account-mail="admin@example.com" --site-mail="admin@example.com" --uri="localhost:8888" --verbose --debug.
  6. The installation will fail. If you're running #68, you'll see: Invalid field settings detected. The `billing_profile` field on the `commerce_order` entity type has one or more missing target bundles: `customer`. If you print instead of throw that error, you'll THEN see A resource type with the name `profile--customer` does not exist. Ensure that the `billing_profile` field on the `commerce_order` entity type has declared all of its dependencies, either via config or the providing module's info file..
mglaman’s picture

#101 came to the same conclusion I had in #53, but my fix did not apply for @Morbus Iff.

I think this issue deserves to go back to RTBC as it helps track down the problem. The issue we're experiencing is a race condition on route rebuilds and config import. Where there is a config entity bundle not yet present for a base field.

g_miric’s picture

Hi all,

Here is my case and how to resolve it:
I used JSON:API Extras to override resources and after that, I exported related configs to a custom module.
After updating the core to 8.8.0 I got the error.

There were 2 issues:
1. I overrode "menu_link", and after update the resource type was changed to "menu_link_content" and I needed to update that config.
2. I have content entities with no bundles, and when I overrode the and exported I got something like this

...
path: topic
resourceType: topic
resourceFields:
...

and I needed to update the config to

...
path: topic
resourceType: topic--topic
resourceFields:
...

after that it was working fine.

BR0kEN’s picture

@g_miric, because jsonapi doesn't work with renamed resource types. #99 fixes this.

oeklesund’s picture

Updating from 8.7.10 to 8.8.0, I ran into this issue.

I can confirm that applying both patches below solved it for me:
- #99
- #3086307: Improve installer performance by ~20% by rebuilding the router after the entire installation is complete rather than after each module

Rajab Natshah’s picture

Patch #99 is working
Thank you

damontgomery’s picture

Path #99 worked for us as well with a renamed resource type from jsonapi_extras.

hkirsman’s picture

This happens for me after adding #99 and as described in #105

The website encountered an unexpected error. Please try again later.

RuntimeException: Unable to locate the resource type neither by the internal or public name. in Drupal\jsonapi\ResourceType\ResourceTypeRepository->Drupal\jsonapi\ResourceType\{closure}() (line 474 of core/modules/jsonapi/src/ResourceType/ResourceTypeRepository.php).
array_map(Object, Array) (Line: 475)
Drupal\jsonapi\ResourceType\ResourceTypeRepository->getRelatableResourceTypesFromFieldDefinition(Object, Array) (Line: 431)
Drupal\jsonapi\ResourceType\ResourceTypeRepository->Drupal\jsonapi\ResourceType\{closure}(Object)
array_map(Object, Array) (Line: 434)
Drupal\jsonapi\ResourceType\ResourceTypeRepository->calculateRelatableResourceTypes(Object, Array) (Line: 129)
Drupal\jsonapi\ResourceType\ResourceTypeRepository->all() (Line: 115)
Drupal\jsonapi\Routing\Routes->routes()
call_user_func(Array) (Line: 146)
Drupal\Core\Routing\RouteBuilder->rebuild() (Line: 83)
Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild() (Line: 342)
Drupal\Core\Extension\ModuleInstaller->install(Array, 1) (Line: 83)
Drupal\Core\ProxyClass\Extension\ModuleInstaller->install(Array) (Line: 477)
Drupal\system\Form\ModulesListForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 112)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 52)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 591)
Drupal\Core\Form\FormBuilder->processForm('system_modules', Array, Object) (Line: 320)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 91)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 85)
hodba’s picture

The same error of #108 happened with me as well. Drupal 8.8.1 with Lightning profile enabled

BR0kEN’s picture

#108: what is the resource that cannot be located?

amen’s picture

I'm on 8.8.1.

Applying the patches from #99 and the one from #3086307, as described in #105, did not solve this for me.

BR0kEN’s picture

It would be awesome if you could provide the additional information to help to resolve this faster.

Saying "it's not working" doesn't help at all.

@amen, what error do you have? Is it the same as in #108? Can you find the exception with Unable to locate the resource type neither by the internal or public name., put this code before and do the steps to get the error again?

      var_dump(
        $entity_type_id, 
        $target_bundle,
        array_keys($resource_types),
        array_map(function ($resource_type) {
          return [
            $resource_type->getEntityTypeId(),
            $resource_type->getTypeName(),
            $resource_type->getBundle(),
          ];
        }, $resource_types)
      );
robin.ingelbrecht’s picture

I agree with @BR0kEN. Can we add the additional info in the runtime exception?

ronaldmulero’s picture

Patch #99 allowed me to upgrade a JSON Extras 8.x-3.13 enabled site from core 8.7.11 to 8.8.2. Thank you.

vgardner’s picture

Getting the same error as #108 after applying patch #99. Running on Drupal 8.8.2. Happens consistently even after reinstalling the jsonapi module.

BR0kEN’s picture

@vgardner, any chance you can do what's described in #112?

lamp5’s picture

@vgardner

Happens consistently even after reinstalling the jsonapi module.

reinstall or re enabling ? Because jsonapi is in core.

BR0kEN’s picture

@lamp5, Drupal no longer use enable/disable words. Even the Extend page says Install. Moreover, I doubt the patch can be applied to contrib.

vgardner’s picture

Thanks for the quick response @BR0kEN. I've managed to fix the issue by using the debug info output by following your comment on #112.

Context:
The D8 site I was trying to install Json API on had been migrated from a D7 site. It turns out there were two entities that hadn't been created during the migration, a Content type and a Paragraph type. So the problem was solved after I created those two manually with the exact machine names being output by debugging info from #112 (plus applying patch #99).

Steps:
1. Installed Json:API (without patch #99)
2. Applied patch #99.
3. Included debugging info from #112.
4. Ran drush cr, received output stating that "paragraph" and "machine_name_of_paragraph_type" could not be located.
5. Created the missing paragraph manually (with exact machine name).
6. Ran drush cr, received with output stating that "node" and "machine_name_of_content_type" could not be located.
7. Created missing content type manually (with exact machine name).
8. Ran drush cr, all worked ok.
9. Ran drush pm-uninstall jsonapi
10. Ran drush en jsonapi. Json API worked without any errors.

Also, FYI I tried a clean install of Drupal 8.8.2, I did not encounter this issue at all. So I'm guessing there's a case during migration where if certain entities are not created properly, we might run into this exception. I'm happy to provide any other info.

BR0kEN’s picture

Wow, thanks for your input!

Might be the problem exist. I see one possible scenario:
- create the content type;
- clear cache;
- remove content type;
- clear cache.

There's a little chance that on the last step the ResourceTypeRepository will use cached entity definitions where staled content type will be present and for which resource creation won't be possible. Need to test that.

BR0kEN’s picture

I was unable to reproduce. I'm wondering how I can get stale entity type definitions that exist in cache only (#119 proves this).

BR0kEN’s picture

I guess I got it. We take entity type and bundle from field settings. Those entity types and bundles may easily be missing. I'll try to provide a test.

    $entity_type_id = $item_definition->getSetting('target_type');
    $handler_settings = $item_definition->getSetting('handler_settings');
BR0kEN’s picture

This patch should fix the issue and inform about broken configurations.

BR0kEN’s picture

FileSize
19.7 KB
3.16 KB

And the proving test case.

The previous implementation was trying to create resource types based on entity type ID and bundle(s) from field configuration. In case the entity type/bundle no longer existed the exception has been thrown. The new patch will produce a warning that notifies about a broken configuration that must be amended.

arefen’s picture

Patch #124 fixed my problem

super_romeo’s picture

Patch #124 suit for D8.8.3 also.

hanoii’s picture

I got here because of this error as well as another fatal error:

I am confused about the issue here. The patch at #124 gave me the following errors:

[warning] The "field_paragraphs" at "node:faq" references the "paragraph:x" entity type that does not exist. Please take action. ResourceTypeRepository.php:474
[warning] The "field_paragraphs" at "paragraph:y" references the "paragraph:x" entity type that does not exist. Please take action. ResourceTypeRepository.php:474
[warning] The "field_paragraphs" at "paragraph:z" references the "paragraph:x" entity type that does not exist. Please take action. ResourceTypeRepository.php:474
[error]  withRelatableResourceTypes() must be called before getting relatable resource types. 

Now, paragraph:x definitely exists and yes, it was renamed to something el through jsonapi_extras. Although it was mentioned here, the error implied the entity was not there, not that it was renamed or anything which would make more sense if the idea of this if to pinpoint issues.

I sort of understand this is an issue with jsonapi_extras, but what does this mean? Shouldn't we be able to rename the url or resource type through jsonapi_extra or is there something else jsonapi_extra should be doing to cope with this?

The fatal error was a nasty one to find, and also jsonapi_extra to blame, but unrelated to this issue.

hanoii’s picture

I think that #3106297: JSON:API (Core) 8.8x is incompatible with jsonapi_extras config is probably the issue reported on the jsonapi_extras side.

BR0kEN’s picture

[warning] The "field_paragraphs" at "node:faq" references the "paragraph:x" entity type that does not exist. Please take action. ResourceTypeRepository.php:474
[warning] The "field_paragraphs" at "paragraph:y" references the "paragraph:x" entity type that does not exist. Please take action. ResourceTypeRepository.php:474
[warning] The "field_paragraphs" at "paragraph:z" references the "paragraph:x" entity type that does not exist. Please take action. ResourceTypeRepository.php:474

The things you are describing are weird enough. Am I correct assuming this is your entity structure?

node:faq
  - field_paragraphs
    - paragraph:x
paragraph:y
  - field_paragraphs
    - paragraph:x
paragraph:z
  - field_paragraphs
    - paragraph:x
+++ b/core/modules/jsonapi/src/ResourceType/ResourceTypeRepository.php
@@ -510,7 +514,36 @@ protected function isReferenceFieldDefinition(FieldDefinitionInterface $field_de
+    if (isset($resource_types["$entity_type_id--$bundle"])) {
+      return $resource_types["$entity_type_id--$bundle"];
+    }

The above code from #124 takes care of locating a resource by internal ID (that is not renamed by JSON:API Extras). If the resource was renamed, the below logic starts a lookup by comparing entity type ID & bundle across all available resources you have. Only if these two lookups haven't found the resource the warning will bubble.

+++ b/core/modules/jsonapi/src/ResourceType/ResourceTypeRepository.php
@@ -510,7 +514,36 @@ protected function isReferenceFieldDefinition(FieldDefinitionInterface $field_de
+    foreach ($resource_types as $resource_type) {
+      if ($resource_type->getEntityTypeId() === $entity_type_id && $resource_type->getBundle() === $bundle) {
+        return $resource_type;
+      }
+    }
+
+    return NULL;
   }

Could you please provide a real configuration so I am able to help? Right now I think there is an error on your side rather than something wrong with #124.

Offtopic: I've replicated the needed functionality (fields rename, entity types disabling and adding includes by default) of JSON:API Extras by a single event subscriber. This was done not of a good life: the last (almost) two years jsonapi_extras loses the race to jsonapi that is developed more actively.

hanoii’s picture

The things you are describing are weird enough. Am I correct assuming this is your entity structure?

Yes, that is the correct entity structure.

The above code from #124 takes care of locating a resource by internal ID (that is not renamed by JSON:API Extras). If the resource was renamed, the below logic starts a lookup by comparing entity type ID & bundle across all available resources you have. Only if these two lookups haven't found the resource the warning will bubble.

Hmm, I'd have to try debugging this if I have more time, however the "Resource type" was also renamed from `paragraph--x` to `paragraph--item` as well as the path, so I wonder if that has anything to do with that?

Could you please provide a real configuration so I am able to help? Right now I think there is an error on your side rather than something wrong with #124.

What configuration are you looking for? In reality the only thing changed was paragraph--x to paragraph--item and the path from /paragraph/x to /paragraph/item

BR0kEN’s picture

What do you have in target_bundles for field.field.node.faq.field_paragraphs.yml?

hanoii’s picture

What do you have in target_bundles for field.field.node.faq.field_paragraphs.yml?

target_bundles: null

I should also add that disabling jsonapi_extras prevents this warnings from appearing.

BR0kEN’s picture

Could you please run the following Drush commands and paste the output?

  1. drush ev "var_dump(\Drupal::service('entity_field.manager')->getFieldDefinitions('node', 'faq')['field_paragraphs']->toArray())"
  2. drush ev "var_dump(\Drupal::service('entity_field.manager')->getFieldDefinitions('node', 'faq')['field_paragraphs']->getItemDefinition()->getSettings())"
  3. drush ev "var_dump(\Drupal::service('entity_type.bundle.info')->getBundleInfo(\Drupal::service('entity_field.manager')->getFieldDefinitions('node', 'faq')['field_paragraphs']->getItemDefinition()->getSetting('target_type')))"
hanoii’s picture

BR0kEN’s picture

Is our x paragraph's bundle present among keys at https://pastebin.com/rB2gZk6S?

hanoii’s picture

@BR0kEN it is, I edited the pastebins to reflect that. Sorry about the name changing btw. At first I did it because of an NDA and just in case but then I got consent but now to keep it with context I edited the pastebins.

Not sure if this is an indication fo anything, but:

- The entity does exist
- I tried removing it from the bundles and importing the configs and the warnings were still there
- Disabling jsonapi_extras prevents the warnings from showing up even though paragraph x is there

BR0kEN’s picture

- I made a clean install of Drupal 8.8.5, JSON:API Extras 3.14.0 and Paragraphs 1.11.0.
- Created the x paragraph with the field_title text field.
- Created the content type with the field_paragraphs that includes all paragraph types.
- Did override the paragraph--x JSON:API resource type to x and path to x.
- Rebuilt the cache.

After these steps I got no errors. Also, in #128 I see the [error] withRelatableResourceTypes() must be called before getting relatable resource types. which may indicate you have some additional customizations of the jsonapi ecosystem.

BR0kEN’s picture

Here are the results in accordance to #134:

array(16) {
  ["uuid"]=>
  string(36) "7d629b86-4653-4672-8d11-895f18f26afd"
  ["langcode"]=>
  string(2) "en"
  ["status"]=>
  bool(true)
  ["dependencies"]=>
  array(2) {
    ["config"]=>
    array(2) {
      [0]=>
      string(35) "field.storage.node.field_paragraphs"
      [1]=>
      string(14) "node.type.page"
    }
    ["module"]=>
    array(1) {
      [0]=>
      string(26) "entity_reference_revisions"
    }
  }
  ["id"]=>
  string(26) "node.page.field_paragraphs"
  ["field_name"]=>
  string(16) "field_paragraphs"
  ["entity_type"]=>
  string(4) "node"
  ["bundle"]=>
  string(4) "page"
  ["label"]=>
  string(10) "Paragraphs"
  ["description"]=>
  string(0) ""
  ["required"]=>
  bool(false)
  ["translatable"]=>
  bool(false)
  ["default_value"]=>
  array(0) {
  }
  ["default_value_callback"]=>
  string(0) ""
  ["settings"]=>
  array(2) {
    ["handler"]=>
    string(17) "default:paragraph"
    ["handler_settings"]=>
    array(3) {
      ["negate"]=>
      int(1)
      ["target_bundles"]=>
      NULL
      ["target_bundles_drag_drop"]=>
      array(1) {
        ["x"]=>
        array(2) {
          ["weight"]=>
          int(2)
          ["enabled"]=>
          bool(false)
        }
      }
    }
  }
  ["field_type"]=>
  string(26) "entity_reference_revisions"
}
array(3) {
  ["handler"]=>
  string(17) "default:paragraph"
  ["handler_settings"]=>
  array(3) {
    ["negate"]=>
    int(1)
    ["target_bundles"]=>
    NULL
    ["target_bundles_drag_drop"]=>
    array(1) {
      ["x"]=>
      array(2) {
        ["weight"]=>
        int(2)
        ["enabled"]=>
        bool(false)
      }
    }
  }
  ["target_type"]=>
  string(9) "paragraph"
}
array(1) {
  ["x"]=>
  array(1) {
    ["label"]=>
    string(1) "X"
  }
}

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.

BR0kEN’s picture

bbrala’s picture

@BR0kEN i've used your changes to see if i could fix JSON:API extra's, tests there seem to pass, but perhaps you can have a look there also?

See https://www.drupal.org/project/jsonapi_extras/issues/3069220

eelkeblok’s picture

We are running into this error and I think the reason is that config dependencies are not making sure everything is in place before the routes are rebuilt;

I am getting failures on a few Paragraph types that were added recently and are *not* present in the database I am running a deployment against. I am getting this error because the resources for those paragraph types in the array passed to Routes::hasNonInternalTargetResourceTypes() has NULL values, presumably because those paragraph types don't actually exist, eventhough the "parent" resource is referring to them.

Of course, if the config import were able to complete, everything would be fine, but we are currently in a catch 22 situation where the config import can't complete because halfway through an error is thrown because JSON:API is trying to rebuild routes for a resource that is essentially still incomplete. This is in core 8.8.8 with jsonapi_extras.

Edit: I now worked around the issue by importing the two offending paragraph types in an update hook (which ensures they are available before the jsonapi_extras resource is imported), which seems to do the trick. I guess this means this is an issue in jsonapi_extras, that should list field configurations as dependencies to a resource definition (this would in turn ensure the paragraph types get imported, I suppse). This is all just theory, but maybe it helps someone to get to the bottom of this.

eelkeblok’s picture

I am happy to report that the patch for #3069220: Drupal 9 Deprecated Code Report does indeed solve my issue (there is more to that issue than the title, although it looks like the changes are in fact needed to get the module to be compatible with D9).

bbrala’s picture

The patch to jsonapi_extra's has been released, please update if you have these issues since that should filter out some noise.

podarok’s picture

#124 patch for Drupal 8.8.3 does work. Thank you, BR0kEN

dilipsingh02’s picture

Thanks,

I have tested this patch for core 8.9.3 and its working for me.

elizoller’s picture

#124 Patch worked on 8.9.4

dilipsingh02’s picture

Status: Needs review » Reviewed & tested by the community
bbrala’s picture

@podarok, @dilipsingh02, @elizoller

I have a question for you guys; Do you use jsonapi_extras? If so, what version do you use? I still kinda suspect this was a jsonapi extra's issue, which was adressed recently. But to be sure we would need some confirmation.

damondt’s picture

Latest patch #141 works for 8.8.8

dilipsingh02’s picture

Hi @bbrala,

No I am not using "jsonapi_extras" on my website.

Thanks
Dilip

mglaman’s picture

This happens on install with a Drupal profile using JSON:API, regardless if using Extras or customizations, it seems.

Arlina’s picture

In our case, we got this error trying to install commerce_product and other commerce submodules on a Drupal 8.9.1 site with core JSON API installed (not using jsonapi_extras). Patch #124 worked.

naveenvalecha’s picture

I also encountered with this issue today with Core json API and Json API extras installed. I was installing commerce_product and its dependencies. I used the patch in #124 which fixed the issue. We're using the Drupal core 8.9.2.

podarok’s picture

@bbrala - no jsonapi_extras in my case

Nicolas S.’s picture

Patch # 124 helped me find my problem
Thks

bbrala’s picture

Well, think it is safe to assume by now it i not jsonapi extra's that is creating this issue.

gabesullice’s picture

Status: Reviewed & tested by the community » Needs review

This is clearly a major problem for many people, but I'm a bit lost by the current direction of the issue.

I felt that by comment #68, we had a pretty targeted patch that would help identify the source of the people's problems and that we had narrowed down the root cause to one of three non-JSON:API problems: bad configuration, a poorly defined custom base field, or JSON:API Extras.

In #71, I tried to summarize the state of the issue and provide a generally applicable recommendation that would help people debug the source of their broken config/code. #74 confirmed that this recommendation worked well. Getting the patch recommended in #71 to be committed seemed like the path of least resistance.

Around #84, this issue roared back to life, but it was never stated why the recommendations proposed in #71 were inadequate.


@BR0kEN, your series of patches starting in #89 are interesting and I like the direction that they're going, but by #141, they're modifying so much code that it's hard for me to spot the material changes.

I understand that many people find array_(map|reduce) difficult to follow in comparison to a foreach loop, but changing those here makes this patch very difficult to review. I sincerely appreciate all the fixes you made to docblocks ase well, but again, I think they distract from the material changes that you're proposing.

As I said, I do like direction you went because it makes JSON:API more internally consistent, but I wonder if your patch doesn't actually belong in #3105318: Add a public API for aliasing resource type names. What would you think about moving you changes there and finishing that patch?

If you would like to move all of the the docblock and array_reduce => foreach changes to a small, separate "Task" issue, I promise to review it and quickly RTBC it. Then this issue (or #3105318 if we move there) can be hyper-focused on material changes.


Unfortunately, I think this needs to be moved out of RTBC because it's not really ready to be committed without a proper review.

Hong Cai’s picture

#124 works for me since drupal 9 has involved jsonapi into core, as long as the targeted module is drupal/core instead of drupal/jsonapi:
"drupal/core":{
"Argument 2 passed to jsonapi":"https://www.drupal.org/files/issues/2020-06-06/2996114-141.patch"
},
then it worked like a charm.

jwilson3’s picture

Patch in #141 worked nicely on 9.0.7 to identify an error I missed after merging a feature branch that contained an entity reference field that was pointing to a node bundle type (events, plural) that had been renamed (event, singular) in the mainline branch.

Helpful warning message upon drush cr after applying this patch:

$ drush cr
 [warning] The "field_events" at "node:news" references the "node:events" entity type that does not exist. Please take action. ResourceTypeRepository.php:437
 [success] Cache rebuild complete.

Thank you to all who've worked hard on this issue.

In addition to the NW changes requested in #159, my only humble suggestion would be to replace "Please take action" with something a little bit closer to the underlying problem, that might help someone in a Google search looking for better instructions.

BR0kEN’s picture

FileSize
11.57 KB

@gabesullice I removed everything unrelated to the problem from #141 (I don't know how you guys read those constructions with array_ functions without the 100% cognitive load of your CPU).

I think that this issue should be prioritized over #3105318: Add a public API for aliasing resource type names because the new feature is new potential issues. It's a good idea to develop that feature with this improvement as it touches the same field. Otherwise, this patch may stop working, making all the work here ignored and require it to be started from scratch.

my only humble suggestion would be to replace "Please take action" with something a little bit closer to the underlying problem

@jwilson3 any suggestions? Nothing comes to my mind. Please take action - is a universal phrase: either remove the field and entity type, or reconfigure the field, or remove the whole site - there is no unique action. Its presence means that something won't work correctly if you do not take action while the main helpfulness of that message is to point to the problematic field and entity type+bundle.

mxr576’s picture

I have custom, handwritten content entities in a project in custom modules. Some entity references taxonomy terms via BaseFieldDefinition::create('entity_reference') that only lives in the site configuration. By using #162 patch and installing the site with the built-in config installer I see these (false) warnings:

[warning] The "XY entity" at "YZ entity:" references the "ZW term" entity type that does not exist. Please take action. ResourceTypeRepository.php:472

I am not sure how this could be resolved... Maybe not displaying these warnings if config sync is running?

gabesullice’s picture

Thanks @BR0kEN! I'll review that soon!

@mxr576, I think that the patch @mglaman referenced should resolve your issue #3086307: Improve installer performance by ~20% by rebuilding the router after the entire installation is complete rather than after each module. Once Drupal 9.1 is released, you can remove the patch.

mxr576’s picture

@gabesullice thanks for the suggestion, I tested the committed patch but it does not solve the issue completely that I reported in #163. Although the number of those warnings have decreased by ~80%. Maybe something still does a rebuild which causes this?

jsutta’s picture

Patch #124 worked for me on D8.9.8.

gabesullice’s picture

Thanks @BR0kEN! I think this is super close. Review below. I've addressed all of my own concerns (all about wording and naming, nothing mechanical). I've also made a test only patch.

IMO, this will be good to go if tests and phpcs look good.


  1. +++ b/core/modules/jsonapi/tests/modules/jsonapi_test_resource_typename_hack/jsonapi_test_resource_typename_hack.services.yml
    @@ -0,0 +1,5 @@
    +  Drupal\jsonapi_test_resource_typename_hack\ResourceType\ResourceTypeRepository:
    

    This is nitpicky, but I don't think we should have a test named "hack".

  2. +++ b/core/modules/jsonapi/tests/modules/jsonapi_test_resource_typename_hack/src/ResourceType/ResourceTypeRepository.php
    @@ -0,0 +1,29 @@
    +  protected function createResourceType(EntityTypeInterface $entity_type, $bundle) {
    +    return new ResourceType(
    +      $entity_type->id(),
    +      $bundle,
    +      $entity_type->getClass(),
    +      $entity_type->isInternal(),
    +      static::isLocatableResourceType($entity_type, $bundle),
    +      static::isMutableResourceType($entity_type, $bundle),
    +      static::isVersionableResourceType($entity_type),
    +      static::getFields($this->getAllFieldNames($entity_type, $bundle), $entity_type, $bundle)
    +    );
    

    For the most part, I like this. I modified this a bit to be a little less coupled to all these static methods. Hopefully that will save a little time in the future.

  3. +++ b/core/modules/jsonapi/tests/src/Kernel/ResourceType/ResourceTypeRepositoryTypeNameHackTest.php
    @@ -0,0 +1,114 @@
    +  public function testGetRelatableResourceTypesFromFieldDefinition() {
    

    Moved this to RelatedResourceTypesTest

  4. +++ b/core/modules/jsonapi/src/ResourceType/ResourceTypeRepository.php
    @@ -473,7 +485,36 @@ protected function isReferenceFieldDefinition(FieldDefinitionInterface $field_de
    +    // Ensure all keys are strings, because numeric values are allowed
    
    +++ b/core/modules/jsonapi/tests/modules/jsonapi_test_resource_typename_hack/jsonapi_test_resource_typename_hack.info.yml
    @@ -0,0 +1,3 @@
    +name: 'JSON:API test resource typeName override'
    

    s/typeName/type name

  5. +++ b/core/modules/jsonapi/tests/modules/jsonapi_test_resource_typename_hack/src/ResourceType/ResourceType.php
    @@ -0,0 +1,21 @@
    +    // That's what JSON:API Extras allows to do.
    

    It's uncommon for core to reference contrib modules. I think I can word this in an agnostic way.

  6. +++ b/core/modules/jsonapi/tests/src/Kernel/ResourceType/ResourceTypeRepositoryTypeNameHackTest.php
    @@ -0,0 +1,114 @@
    +   * JSON:API Extras is used widely and it's hard to imagine how big its
    +   * coverage at existing projects. The project allows renaming resource
    +   * types (e.g. "user---user" to "user") and this negatively affects the
    +   * operability of JSON:API itself.
    

    Good comment. I moved this to the class docblock and made an argument why this test is good for core even if we ignore contrib.

The last submitted patch, 167: 2996114-167-test-only.patch, failed testing. View results

BR0kEN’s picture

The core of the fix remained unchanged which means I like this patch. There is a resolution of this issue blinking on the horizon 😃

bbrala’s picture

Think i need to check how this patch works with extra's tomorrow see if there is some redundancy between those two. I did add some code of the patch to extra's a while back to fix some general issues.

bbrala’s picture

Status: Needs review » Reviewed & tested by the community

I've went through the code, looking good. Good work everyone! RTBC ^^

gabesullice’s picture

WOOT 🥳 Thanks @bbrala!

gabesullice’s picture

#3105318-41: Add a public API for aliasing resource type names is the follow up issue for the @todos introduced in this patch.

The last submitted patch, 167: 2996114-167-test-only.patch, failed testing. View results

The last submitted patch, 167: 2996114-167-test-only.patch, failed testing. View results

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

I've tried to credit everyone who has worked on this issue either by providing patches, reviews that affected the patch or with comments that have given the direction. It's hard because there are so many comments - which also go to show how important this is to land.

The one outstanding concern I have is #163/#165 - I don't think the answer in #164 is quite right - it this patch introduces warnings during the installer that weren't happening before then it'll introduce new problems because people will see a warning for something that is not correct.

I think the easiest way forward here is to recognise that the installer is a rare environment for a site to be it and be pragmatic.

+++ b/core/modules/jsonapi/src/ResourceType/ResourceTypeRepository.php
@@ -423,19 +423,31 @@ protected function calculateRelatableResourceTypes(ResourceType $resource_type,
+      else {
+        trigger_error(
+          sprintf(
+            'The "%s" at "%s:%s" references the "%s:%s" entity type that does not exist. Please take action.',
+            $field_definition->getName(),
+            $field_definition->getTargetEntityTypeId(),
+            $field_definition->getTargetBundle(),
+            $entity_type_id,
+            $target_bundle
+          ),
+          E_USER_WARNING
+        );
+      }

Let's change the else to elseif (!\Drupal\Core\Installer\InstallerKernel::installationAttempted()) { here and add a comment saying only trigger the warning after a site is installed to avoid incorrect error messages.

Once this has been addressed this issue can be put back to rtbc.

BR0kEN’s picture

Status: Needs work » Needs review
FileSize
14.95 KB
1.71 KB
alexpott’s picture

@BR0kEN thanks for the patch. Just a tiny tiny nit.

+++ b/core/modules/jsonapi/src/ResourceType/ResourceTypeRepository.php
@@ -422,6 +423,7 @@
+    $site_installed = !InstallerKernel::installationAttempted();

@@ -432,7 +434,10 @@
+      elseif ($site_installed) {

I'd do else(!InstallerKernel::installAttempted())

Because there's no need to run this code in the happy path. And if this is the only call to it then we can avoid autoloading the code. Yep it is a micro-optimisation for sure but I'm not sure the local variable improves things.

jungle’s picture

+++ b/core/modules/jsonapi/tests/src/Kernel/ResourceType/ResourceTypeNameAliasTest.php
@@ -0,0 +1,87 @@
+  protected function setUp() {

One more nitpick: type hint should be added. Addressing this and #178, and let's land it to 9.2.x first.

jungle’s picture

Version: 9.0.x-dev » 9.2.x-dev
FileSize
15.19 KB
304 bytes
$ cd core && yarn spellcheck:core
yarn run v1.22.4
$ cspell "**/*" ".*" "../composer/**/*" "../composer.json"
core/modules/jsonapi/tests/src/Kernel/ResourceType/ResourceTypeRepositoryTest.php:197:29 - Unknown word (Unskip)
CSpell: Files checked: 15160, Issues found: 1 in 1 files
error Command failed with exit code 1.
  public function testResourceTypeNameAliasing() {
    // When this test is implemented, ensure the the tested behaviors in
    // ResourceTypeNameAliasTest have been covered and remove it. Then remove
    // the jsonapi_test_resource_type_aliasing test module.
    $this->markTestSkipped('Unskip this test in https://www.drupal.org/project/drupal/issues/3105318');
  }

unskip is a new word which failed the spell checking, adding it to the dictionary.

Status: Needs review » Needs work

The last submitted patch, 180: 2996114-180.patch, failed testing. View results

jungle’s picture

Status: Needs work » Needs review
FileSize
15.2 KB
606 bytes

1x: The Drupal\Tests\jsonapi\Kernel\ResourceType\ResourceTypeNameAliasTest::$modules property must be declared protected. See https://www.drupal.org/node/2909426

Fixing

(Edited: wrong patch and interdiff file names, sorry, should be 2996114-182.patch and interdiff-180-182.txt)

Status: Needs review » Needs work

The last submitted patch, 182: 2996114-82.patch, failed testing. View results

jungle’s picture

Status: Needs work » Needs review

It's a random fail.

bbrala’s picture

  1. +++ b/core/misc/cspell/dictionary.txt
    @@ -1825,6 +1825,7 @@ unsets
    +unskip
    

    Perhaps rephrasing is better. `Remove in issue https://www.drupal.org/project/drupal/issues/3105318`

  2. +++ b/core/modules/jsonapi/tests/src/Kernel/ResourceType/ResourceTypeRepositoryTest.php
    @@ -187,6 +187,16 @@ public function testResourceTypeFieldAliasing() {
    +    $this->markTestSkipped('Unskip this test in https://www.drupal.org/project/drupal/issues/3105318');
    

    Here :)

I think its wise to try and avoid new word if possible. Change that and ill RTBC again ^^

jungle’s picture

FileSize
14.89 KB
1.16 KB

#185 good point, thanks @bbrala!

bbrala’s picture

Status: Needs review » Reviewed & tested by the community

Thanks, well done. Looking good ^^

jungle’s picture

+++ b/core/modules/jsonapi/tests/src/Kernel/ResourceType/ResourceTypeNameAliasTest.php
@@ -0,0 +1,87 @@
+  public function test() {

Better to have a meaningful method name probably, testResourceTypeRepository() or ?

bbrala’s picture

Ah yes, `testRepositoryResourceTypeNameAliassing` might be better. Coffee time o_O

jungle’s picture

Changed as suggested in #189. I doubt that it is not being detected as I have not found the evidence here that it's being executed. Stay RTBC.

bbrala’s picture

Better, thanks :)

alexpott’s picture

Version: 9.2.x-dev » 9.1.x-dev
Status: Reviewed & tested by the community » Fixed

Committed and pushed e82556c355 to 9.2.x and 090a1cf064 to 9.1.x. Thanks!

Backported to 9.1.x as this is only improved error reporting and a lot of people are running into this error.

diff --git a/core/modules/jsonapi/tests/src/Kernel/ResourceType/ResourceTypeNameAliasTest.php b/core/modules/jsonapi/tests/src/Kernel/ResourceType/ResourceTypeNameAliasTest.php
index c1811bece7..b2b506c449 100644
--- a/core/modules/jsonapi/tests/src/Kernel/ResourceType/ResourceTypeNameAliasTest.php
+++ b/core/modules/jsonapi/tests/src/Kernel/ResourceType/ResourceTypeNameAliasTest.php
@@ -58,7 +58,7 @@ protected function setUp(): void {
    * @covers ::all
    * @covers ::getByTypeName
    */
-  public function testRepositoryResourceTypeNameAliassing() {
+  public function testRepositoryResourceTypeNameAliasing() {
     $repository = $this->container->get('jsonapi.resource_type.repository');
 
     static::assertInstanceOf(ResourceType::class, $repository->get('user', 'user'));

Fixed spelling mistake on commit.

  • alexpott committed e82556c on 9.2.x
    Issue #2996114 by BR0kEN, gabesullice, jungle, ARUN AK, tengoku, Wim...

  • alexpott committed 090a1cf on 9.1.x
    Issue #2996114 by BR0kEN, gabesullice, jungle, ARUN AK, tengoku, Wim...
rpsu’s picture

Any change patch (or some future modification of it) in #124 will get committed to 8.9.x?

Status: Fixed » Closed (fixed)

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

bsains made their first commit to this issue’s fork.

simohell’s picture

FileSize
19.76 KB

The patch from #124 would not apply with 8.9.19 so I updated the patch and it gets applied.

Hope to get my site updated to D9 soon, though.

bsains’s picture

FileSize
12.15 KB

Thanks @simohell for the patch... beat me to it. However I think you've missed the field validation that was updated in the core for 8.9.19 as per the security advisories. We don't want to roll any of those changes back.

Specifically -

$field->isFieldEnabled()

See attached patch.

bsains’s picture

FileSize
19.78 KB

Looks like I missed some of the tests from #124 - Rerolled.

bsains’s picture

FileSize
19.78 KB

Not my morning... re-added with correct comment #

mxr576’s picture

Please always attach interdiffs with previous patches. #124 was the last known good patch, please use that as a base.
@brains an interdiff with #198 would be also beneficial if you believe something was left out.

simohell’s picture

Patch 201 seems legit. I think I did miss that one thing. I'll add the interdiffs.