TypeError: Illegal offset type in Drupal\Core\Entity\EntityStorageBase->load()

Is this still a problem with the latest dev release?

This appears to be a problem with the load() function accepting mixed types when it should only accept an int. If you send it an array, it will have this problem. Many things in drupal core send this an array and it was never a problem. But in PHP 8.x this results in a fatal error.

Here is a patch that fixes this problem in core when you are using PHP 8.x, in PHP 7.x this is only a warning, not a fatal error but that was changed in PHP 8.x. This problem for us was discovered when trying to use the Migrate module to migrate sites. One of the fixes was to change the ids that were being sent to the proper format (that wasnt possible for us since there was no ID list, it was array[0] = NULL, we have no idea where it came from since it wasnt anything our custom code provided) but core should still be smart enough to handle malformed ids and produce a warning, not a fatal error.

See updated patch
Needs tests.

This actually affects all versions of D8/9, but since 9.5 is going to become 10 and 10 will become 11, makes sense to keep this as D9.5. This also isnt a support request. It's a bug in core. Good catch on the /a and /b paths, forgot to remove docroot.

new patch

phpcbf helped generate patch 08 which was bumped to 09

Explain why you keep setting this to D11 pls. That will cause it to never be put into 9 or 10 which to me is unacceptable.

@crystaldawn, this will never go into 9

9.5 will be EOL November 1st and is currently only getting security advisory releases and the very rare bug fix.
https://www.drupal.org/about/core/policies/core-release-cycles/schedule →

How about 10 then? 11 seems a bit to extreme, this is going to be a pretty common problem for migrations once PHP 8 becomes more used. We have 1600+ sites moving from D7 to D9/10 and this would be a problem for the next several years.

fat fingered a spelling, wow core is tight eh?

wow 1600 sites, maybe wait for D7 LTS to kick in for a few years then upgrade to D12, by then maybe this will be resolved.

@crystaldawn, I suspect this issue is being caused by one of your contrib modules or one of your custom modules or themes.

See related issues and ways this was fixed in other projects.

https://git.drupalcode.org/project/webform/-/commit/cbbf2cb48889afa3d036...
#2901211: AJAX fails for new pages →
related to:
#2901295: Warning: Illegal offset type in isset or empty in Drupal\webform\WebformEntityStorage->load() (line 111 WebformEntityStorage.php) →

Similar, possibly related
#2876229: Warning: Illegal offset type in ContentEntityStorageBase->getFromPersistentCache() →

With that said, I can understand that there's possible related improvements to the exception handling that could be done in core for developer experience to improve this for everyone.

I haven't looked too closely at your patch. Just wanting to see if it passes core tests, so I spun it up on 11.x, the same patch should apply to 10.x and 9.x.

@crystaldawn, I've queued up the patch vs 9.5.x, 10.0.x, 10.1.x, 11.x
I'm just assigning this to 11.x so that it bounces around less. It would likely go into 11.x, 10.1.x and 10.0.x simultaneously
but perhaps only 10.1.x and 11.x, I'm not 100% current on the core policies, they sometimes bend the rules.

Well I know it applies to d9.5 since that is what we're using and we also know that the problem stems from the migrate module (with no custom modules enabled), but to us it seemed like it made sense to fix it in core because in our limited search we found others having the same exact issue but with differing context (such as this issue queue which I hijacked from taxonomy heh). So yes, we could probably plug 10 holes to stop the leaking, but it makes more sense to just turn off the faucet and close them all at once ;)

if there were tests added to the patch and we ran a tests only patch which failed proving core was bad, and prove that the test succeeds with your fix or a variant of the fix then we could perhaps convince the core people to fix this quickly.

@crystaldawn, if you wanted to get to the root contrib/custom cause of this issue you could try some debug techniques that have been very helpful for me recently..

I suggest having a look at the debug technique shown in the link I mentioned here:
https://www.php.net/manual/en/function.debug-print-backtrace.php

I had some good luck with the last example mentioned in the comments , the A, B and C class.

With that said, the others above the last example may be simpler if you have issues try the others. I was able to get the last example working and it was very helpful.

Heh, well I use a bit more than just backtrace. I use xdebug in vscode via breakpoints and I'll tell ya, while it's not difficult, it's VERY time consuming stepping through where the code is going, etc. The task I had to fix this was time limited and this was the best answer I could come up with that I knew would not only fix our current issue, but any future issues as well. If I had the time, I'm 100% confident I could find the root cause and fix that but I still believe this should be handled better in core anyway which is what the patch is meant to assist with. I'm sure someone smarter than me will come along and improve on the patch as it is. At least that's the hope anyway :D But as of right now, it works and thats the bottom line I suppose.

@crystaldawn,

The core tests are asserting exceptions of type "InvalidArgumentException" match expected exception "AssertionError".

So it looks like core is expecting contrib to be cleaner than Jesus Christ and Moses is holding the candle.