TypeError: Argument 2 passed to SearchApiConverter::__construct() must implement EntityRepositoryInterface

Did you try clearing the cache? And can you confirm that the search_api.services.yml file contains the following:

  paramconverter.search_api:
    class: Drupal\search_api\ParamConverter\SearchApiConverter
    arguments: ['@entity_type.manager', '@entity.repository', '@tempstore.shared', '@current_user']
    tags:
      - { name: paramconverter, priority: 10 }
    lazy: true

I have the same error, clearing cache is not possible

I am experiencing the same error after running composer update. I can not run drush or access the site via web browser without encountering this same error, so I am unable to clear cache.

Hi,
I have the same problem and I confirm that the file search_api.services.yml contains what drunken monkey asked =)
...
But my update is made thru the web admin interface
Greatings

Same error, I confirm to have #2 lines, I resolved using the "rebuild script" here: https://www.drupal.org/docs/user_guide/en/prevent-cache-clear.html

FWIW, I received the same error while also updating via composer and running drush updb. (Core is still at 8.8.1, pending additional contrib updates, when it will be updated as well.) In my case, drush cr corrected the issue.

I had the same issue, clearing caches using drush fixed the issue: drush cr

Anyone know how I can clear cache without using drush?

I have this issue too and no way around it atm.

Anyone know how I can clear cache without using drush?

https://www.drupal.org/docs/user_guide/en/prevent-cache-clear.html

Rebuild script is also not working

I had the same issue when updating with composer and using this command:
drush updb -y ; drush cr

But then if i try to launch again drush updb it says: No pending updates.

So i assume the correct way would be to clear cache first then launch the update.

Isn't it also caused by Changes to service definitions can cause fatal errors until services cache is cleared (2918906)?

"the website encountered an unexpected error. Please try again later.
TypeError: Argument 2 passed to Drupal\search_api\ParamConverter\SearchApiConverter::__construct() must implement interface Drupal\Core\Entity\EntityRepositoryInterface, instance of Drupal\Core\TempStore\SharedTempStoreFactory given, called in /home/fkelly5/public_html/drupal8/core/lib/Drupal/Component/DependencyInjection/Container.php on line 277 in Drupal\search_api\ParamConverter\SearchApiConverter->__construct() (line 53 of modules/search_api/src/ParamConverter/SearchApiConverter.php)."

after running update from the available updates page then running update.php. Went back and ran update.php a second time and the error cleared. Some of us on shared hosting may not have direct drush access even though we may use it all the time on our local site environments. Looks like update.php takes care of the problem.

#2 allowed me to drush cr without errors.

#14 >> Went back and ran update.php a second time and the error cleared.

This works for me.

Re-running update.php fixes the issue for me.

Had the same issue today (and a small heart attack). Could not run standard drush cr but running drush updb -y ; drush cr after fixed it...finally. Why doesn't the clear cache run automatically after updates?

Hi all,

After an update I've received the same error.

"composer dumpautoload" worked for me.

Regards

As I suggested in #13 the actual issue is that this commit has changed the signature (parameter list) of the paramconverter service and because of that Drupal's service container is unable to load the service until (all) service defintions are not being rebuilt again. drush cr for sure, I guess then the updates.php also, invalidates container's cache in the database and forces the container to rebuild the service definitions, this is the reason why the site starts working again. (#18)

This issue usually does not occur in core components because they do not change their parameter list and if a new parameter gets introduced then it becomes optional until Drupal 9.

#14 >> Went back and ran update.php a second time and the error cleared.

This works for me too.

I've also got this error.
Cache clear or updb might have solved it

Here is the detailed error log if interested:

error   php  TypeError: Argument 2 passed to Drupal\search_api\ParamConverter\SearchApiConverter::__construct() must implement interface Drupal\Core\Entity\EntityRepositoryInterface, instance of Drupal\Core\TempStore\SharedTempStoreFactory given, called in
                                      /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php on line 277 in Drupal\search_api\ParamConverter\SearchApiConverter->__construct() (line 53 of
                                      /var/www/drupalvm/modules/contrib/search_api/src/ParamConverter/SearchApiConverter.php) #0 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(277):
                                      Drupal\search_api\ParamConverter\SearchApiConverter->__construct(Object(Drupal\Core\Entity\EntityManager), Object(Drupal\Core\TempStore\SharedTempStoreFactory), Object(Drupal\Core\Session\AccountProxy))
                                      #1 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(173): Drupal\Component\DependencyInjection\Container->createService(Array, 'drupal.proxy_or...')
                                      #2 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(487): Drupal\Component\DependencyInjection\Container->get('drupal.proxy_or...', 1)
                                      #3 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(326): Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array)
                                      #4 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(173): Drupal\Component\DependencyInjection\Container->createService(Array, 'paramconverter_...')
                                      #5 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(487): Drupal\Component\DependencyInjection\Container->get('paramconverter_...', 1)
                                      #6 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(237): Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array)
                                      #7 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(173): Drupal\Component\DependencyInjection\Container->createService(Array, 'access_manager')
                                      #8 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(487): Drupal\Component\DependencyInjection\Container->get('access_manager', 1)
                                      #9 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(237): Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array)
                                      #10 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(173): Drupal\Component\DependencyInjection\Container->createService(Array, 'redirect.checke...')
                                      #11 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(487): Drupal\Component\DependencyInjection\Container->get('redirect.checke...', 1)
                                      #12 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(237): Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array)
                                      #13 /var/www/drupalvm/core/lib/Drupal/Component/DependencyInjection/Container.php(173): Drupal\Component\DependencyInjection\Container->createService(Array, 'na_regex_redire...')
                                      #14 /var/www/drupalvm/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(105): Drupal\Component\DependencyInjection\Container->get('na_regex_redire...')
                                      #15 /var/www/drupalvm/vendor/symfony/http-kernel/HttpKernel.php(127): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.request', Object(Symfony\Component\HttpKernel\Event\GetResponseEvent))
                                      #16 /var/www/drupalvm/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
                                      #17 /var/www/drupalvm/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
                                      #18 /var/www/drupalvm/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
                                      #19 /var/www/drupalvm/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
                                      #20 /var/www/drupalvm/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
                                      #21 /var/www/drupalvm/core/modules/ban/src/BanMiddleware.php(50): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
                                      #22 /var/www/drupalvm/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
                                      #23 /var/www/drupalvm/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
                                      #24 /var/www/drupalvm/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
                                      #25 /var/www/drupalvm/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
                                      #26 /var/www/drupalvm/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
                                      #27 {main}.

Thanks a lot, mxr576, for tracking down the root cause for this! And thanks, everyone, who shared a workaround for this.
Unfortunately, I don’t really see anything we could do to fix this issue – unless I’m mistaken? (If there is a way for us to fix this in the code, I could maybe do a quick 1.17 release fixing this.)

So, I fear the best we can do is provide clear instructions for anyone encountering this problem. I tried to now provide them right in the issue summary at the top. Could you please review whether you find them accurate, based on your findings/experience?
I also linked this issue in the release notes, to hopefully make a few others aware before they upgrade.

Anyways, thanks for your comments here, and sorry for the disruption!

OK, I guess we could just adapt \Drupal\search_api\ParamConverter\SearchApiConverter::__construct() to, temporarily, remove type hints and allow both calls with the old and the new parameters. And then remove that “BC” code again after one or two releases, to make reasonably sure that everyone has now updated.

However, the problem with that is that we have now increased our required Core version to 8.8, and didn’t plan to make a new release so soon. (As this would mean that people on Drupal 8.7 can’t upgrade to the latest release – also not getting the fix for this issue.)
So either we still go ahead, or we create a new release based not off of HEAD/the dev version, but based on the 8.x-1.16 release tag, just adding this one new commit. (Which could cause problems for everyone updating from a dev version, as that would essentially be dorn-grading then.)

Any input on this from people experienced with release management?

I think all contrib developers are suffering from #2918906. Drupal core has an easily bail out option with its backward compatibility promise because they can get rid of any workarounds (like nullable parameters) from core with Drupal 9. If you are a contrib developer, you are on your own, meaning you have to figure out your own BC promise and release schedule and supported versions.

And then remove that “BC” code again after one or two releases

I do not think that would work, because you cannot be sure when someone will update from 1.X to 1.Z. The removal of this compatibility layer can only happen in the 2.x version of the module.

So either we still go ahead, or we create a new release based not off of HEAD/the dev version, but based on the 8.x-1.16 release tag, just adding this one new commit. (Which could cause problems for everyone updating from a dev version, as that would essentially be dorn-grading then.)

As the problematic release is quite old now, I would just add a note to the release notes and the upcoming 3-5 that if they are trying to update from an older version they should clear caches before updb and cim.

Hm, based on the usage statistics, it seems quite a few people are still using 1.15. Perhaps because we messed up several things with 1.16.

So, maybe we should still add a BC layer for this after all? Something like the attached patch? Might still prevent trouble for thousands of people …
Feedback/input welcome!

Feedback would have been nice, but I guess let’s just do this and hope for the best. As said above, this might prevent problems for a lot of people.

Created the change record and committed.

Couldn't find an answer. I decided on my own

Here is my solution:

composer require symfony/event-dispatcher:"4.3.4 as 3.4.99"

composer update drupal/core --with-dependencies
composer update
composer require "drupal/search_api_solr:4.x-dev"

http://SITENAME/update.php
All OK!