Cannot connect to solr server after upgrading Acquia Connector to 3.0.1

Were you able to fix this by trying to reconnect with your acquia cloud credentials? I reached out via your contact form, but no response. Would love to see what you're running into since we cannot reproduce this internally.

I confirm that we have the same issue with our project.
Recently, we upgraded Drupal Core using Acquia/Lightning distribution to version 3.4.10.

Our current setup:
Drupal - 8.9.13
Acquia Connector - 3.0.2
Acquia Search - 2.1.24
Search API - 8.x-1.19
Search API Solr - 8.x-1.10
solarium/solarium - 6.0.4

When we try to open: /admin/config/search/search-api/server/acquia_search_server the error is displayed

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

Solarium\Exception\UnexpectedValueException: Neither collection nor core set. in Solarium\Core\Client\Endpoint->getBaseUri() (line 289 of /var/www/vendor/solarium/solarium/src/Core/Client/Endpoint.php).
Drupal\search_api_solr\SolrConnector\SolrConnectorPluginBase->handleHttpException(Object, Object) (Line: 846)
Drupal\search_api_solr\SolrConnector\SolrConnectorPluginBase->execute(Object) (Line: 499)
Drupal\search_api_solr\SolrConnector\SolrConnectorPluginBase->getDataFromHandler('/admin/system', ) (Line: 438)
Drupal\search_api_solr\SolrConnector\SolrConnectorPluginBase->getCoreInfo() (Line: 384)
Drupal\search_api_solr\SolrConnector\SolrConnectorPluginBase->getSolrVersion() (Line: 541)
Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend->viewSettings() (Line: 191)
Drupal\search_api\Entity\Server->viewSettings() (Line: 241)
template_preprocess_search_api_server(Array, 'search_api_server', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('search_api_server', Array) (Line: 431)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 444)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 200)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 67)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->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: 115)
Drupal\shield\ShieldMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I can also confirm we're seeing the same thing on Drupal 9.1.5 with:

Acquia Connector 3.0.2
Acquia Search 2.1.24
Search API 1.19
Search API SOLR 1.10
Solarium 6.1.1

So the 'possible cores' is returning null for anything but production, which is expected. I added a check after readonly mode is set to try to set it to the first available core on the account. This should work for those using the account id instead of one with a suffix.

Test this patch and let me know how it goes, and I can commit it.

Won't #7 prevent the use of non-production search cores in general?

In our setup we have...

dev -> dev search core
dev1 -> dev search core
dev2 -> dev search core
devN... -> dev search core
test -> test search core
prod -> prod search core

After #7
dev -> prod search core (read only)
dev1 -> prod search core (read only)
dev2 -> prod search core (read only)
devN... -> prod search core (read only)
test -> prod search core (read only)
prod -> prod search core

Am I missing something?

Nevertheless, after applying #7, we're still getting HTTP/500 on the /admin/config/search/search-api/server/acquia_search_server route.

I think we may want to address this in 2 ways:

• When no core is available, ideally there should be some state where the site does not throw fatal errors/exceptions (you can still use the site) but fall back to some "fake" Solr connection that won't ever work. Like "http://localhost:9999/acquia-search-missing-index-see-docs" or something, which wouldn't break Drupal but just show warnings when needed.
• This next piece is the rationale of why this module dropped the logic to automatically pick "the production core in read-only mode" (like the provided patch in #7 seems to want to implement). We dropped this during the design of this new version of the module, because there was still the danger of corrupting the production (or some other index) unintentionally from a development/other environment. Thus, the intended way to now properly connect to another core (read-only or not) is to override the connection with the provided options in the module's README. Of course, this decision is arguable and we may want to change it, I just wanted to explain why the module behaves as it does.

Not sure if it'd help in debugging or not, but here's how we've had our settings.php set up for the past 4 years.

if ( the environment is one of our dev environments ) {
  $config['acquia_search.settings']['connection_override'] = [
    // The settings to connect to our dev index.
  ];
}

The connection override part seems to no longer work with the latest versions of things.

It's starting to sound like this might be a separate issue.

Hmm, the connection override variable has changed a few times over the last few years, but this is what should be used today:

## For Search 2.x Solr 3/4
$config['acquia_search.settings']['default_search_core'] = 'ACBD-123456';

## For Search 3.x Solr 7
$config['acquia_search.settings']['override_search_core'] = 'ABCD-123456.dev.DBNAME';

Where dbname is the database name found in cloud ui for the environment you want to connect to.

Let me know if that works for you!

Hi,

"default_search_core" is not a 1-2-1 replacement of functionality for "connection_override", connection_override allowed me to override the connection information to a solr server I had running in docker for local development, e.g. this is what I was able to use with Acquia Search 8.x-1.*:

$config['acquia_search.settings']['connection_override'] = [
  'scheme' => 'http',
  'port' => 8983,
  'host' => 'solr',
];

Correct me if I am wrong, but the "default_search_core" variable seems to allow me to define a core id, to connect to, that only exists on Acquia cloud. But I don't want to connect to Acquia cloud, I want to use my local solr server in docker so I can develop and test the update. Even so, it's really unclear how to set this up in the first place. I've been trying to follow the instructions at https://docs.acquia.com/acquia-search/multiple-cores/override/, until I've realized that support for a non-acquia hosted solr core seems to have been dropped.

I am in the process of trying to upgrade to Solr 7 on an existing site. The combination of this module seeming unable to use anything but Acquia hosted solr cores, and that upgrading Solr versions in the Acquia dashboard seems to apply to ALL Environments, means that I can't do any development and testing without pulling the trigger to permanently upgrade to Solr 7 on production. Which is not really feasible.

Ahh, I see what you're trying to do. Unfortunately the 'Acquia Search Server' uses a special class that authenticates via an event subscriber dispatched from solarium. Unfortunately this means you probably need to have a local server that you associate your acquia search index onto.

I created a ticket in our internal backlog to research this a bit more, because I totally understand what you're trying to do, especially if you have the search configuration we use deployed to your local docker solr server.

Just a follow up that our TAM provisioned us additional cores for our extra dev environments so that we no longer needed the overrides.

Things are going smoothly now in our particular case. All it took was 6 more cores...heh.

Hi
have placed below in settings.php as per https://docs.acquia.com/acquia-search/multiple-cores/override/
$config['acquia_search.settings']['override_search_core'] = 'ABCD-12345.prod.mysite';

but getting below as solr server status
search_api_solr.module server ID: test
URL: https://localhost:8083/
Acquia Search Solr module automatically selected the proper Solr connection based on the detected environment and configuration.
Solr core is currently unreachable.
Solr core authentication check fails.

and if removed $config['acquia_search.settings']['override_search_core'] from settings.php it worked with core provided in "search_api_server.test.yml" but not able to override core as per environment.

override_search_core is not working as expected in latest version.

Plesae suggest any solution.

Hi

I have tried to apply patch for 2.1.25 version but not worked. So I have modified patch it is now working fine for 2.1.25 version.
So for version 2.1.25 try to use acquia_search_3202247-8.patch

Thanks

Backported these changes in this patch from the old Acquia Search Solr module. If you resave the configuration form, it should wipe out the old values.

Patch #7 throws:

( ! ) Fatal error: Cannot redeclare Drupal\acquia_search\PreferredSearchCoreService::getAvailableCores() in /var/www/xyz/docroot/modules/contrib/acquia_search/src/PreferredSearchCoreService.php on line 279

Patch #18 works

Patch #21 is not applying

In the Acquia environment Drupal uses the $ah_env attribute to determine which Solr core to use. If you're somewhere else without access to that you you can manually set which core to use by defining the "acquia_search.settings.default_search_core" in your settings.php. That would look something like:

$config['acquia_search.settings'] = [
  'default_search_core' => '[core]',
];

Patch 18 looks good to me. Fixed, I hope!