SearchApiException: Search server with machine name Foo specifies illegal service class search_api_db_service

Does this still happen with the latest module version? Error reporting has been improved a lot since then.
If this is fixed, please mark it as such in the "Status" field.

I really don't know how this could happen. We especially have code to prevent exactly this situation:

/**
 * Implements hook_modules_enabled().
 */
function search_api_modules_enabled() {
  // New modules might offer additional item types or service classes,
  // invalidating the cached information.
  drupal_static_reset('search_api_get_item_type_info');
  drupal_static_reset('search_api_get_service_info');
}

Maybe try to get a timeline of when this hook is called in relation to the other hooks, and how search_api_get_service_info() behaves.

I solved this problem in my local environment (search_api_db , search_api , search_api_solr version 1.4) by simply deleting the row in the tables that contained the problematic search server entry.

in my case I am using a database search not a solr search and in my case I got the error
SearchApiException: Unknown server solr_server specified for index job_search. in SearchApiIndex->server() (line 377 of modules/search_api/includes/index_entity.inc).

so I of course made a backup of the database first and then tested this (it worked for me):
delete from search_api_index where id = 2; #where 2 is the id of the search_api_index record that is causing the problem, you'll have to find out what id is problematic by looking at the rows in this table the machine name should correspond to the unknown server you're wanting to remove.

you might also need to delete a row in the search_api_server table if it is related to the search_api_index record you are having problems with.

after this I was able to reindex and index the content.

warning: please backup your database and try this on a copy of your site in a qa or dev environment.

This happened to me as well but with the Solr service. For some reason search_api_solr_service became disabled. Had to reenable it :)

This ticket should be marked as works as expected.

The case where this happens is when one of the search_api modules is not activated in Drupal.
Something these features seem to have a knack of doing. (in my case was search_api_solr)

Hi,

I think I might have experienced the same problem. I'm working on moving a site onto Acquia Cloud, and at the moment when I enable the search_api_acquia module for the new server I get:

exception 'SearchApiException' with message 'Search server with machine name solr_server specifies illegal service class acquia_search_service.' in
/var/www/html/docroot/sites/all/modules/contrib/search_api/includes/server_entity.inc:138
Stack trace:
#0 /var/www/html/docroot/sites/all/modules/contrib/search_api/includes/server_entity.inc(217): SearchApiServer->ensureProxy()
#1 /var/www/html/docroot/sites/all/modules/contrib/search_api/search_api.module(581): SearchApiServer->postCreate()
#2 [internal function]: search_api_search_api_server_insert(Object(SearchApiServer))
#3 /var/www/html/docroot/includes/module.inc(957): call_user_func_array('search_api_sear...', Array)
#4 /var/www/html/docroot/sites/all/modules/contrib/entity/includes/entity.controller.inc(930): module_invoke_all('search_api_serv...', Object(SearchApiServer))
#5 /var/www/html/docroot/sites/all/modules/contrib/entity/includes/entity.controller.inc(450): EntityAPIControllerExportable->invoke('insert', Object(SearchApiServer))
#6 /var/www/html/docroot/sites/all/modules/contrib/entity/includes/entity.controller.inc(949): EntityAPIController->save(Object(SearchApiServer), NULL)
#7 /var/www/html/docroot/sites/all/modules/contrib/entity/includes/entity.inc(333): EntityAPIControllerExportable->save(Object(SearchApiServer))
#8 /var/www/html/docroot/sites/all/modules/contrib/entity/entity.module(287): Entity->save()
#9 /var/www/html/docroot/sites/all/modules/contrib/entity/entity.module(946): entity_save('search_api_serv...', Object(SearchApiServer))
#10 /var/www/html/docroot/sites/all/modules/contrib/entity/entity.module(979): _entity_defaults_rebuild('search_api_serv...')
#11 [internal function]: entity_modules_enabled(Array)
#12 /var/www/html/docroot/includes/module.inc(957): call_user_func_array('entity_modules_...', Array)
#13 /var/www/html/docroot/includes/module.inc(516): module_invoke_all('modules_enabled', Array)
#14 /home/www-data/.composer/vendor/drush/drush/commands/core/drupal/environment_7.inc(143): module_enable(Array)
#15 /home/www-data/.composer/vendor/drush/drush/commands/pm/pm.drush.inc(1180): drush_module_enable(Array)
#16 [internal function]: drush_pm_enable('feature_search_...')
#17 /home/www-data/.composer/vendor/drush/drush/includes/command.inc(422): call_user_func_array('drush_pm_enable', Array)
#18 /home/www-data/.composer/vendor/drush/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#19 [internal function]: drush_command('feature_search_...')
#20 /home/www-data/.composer/vendor/drush/drush/includes/command.inc(199): call_user_func_array('drush_command', Array)
#21 /home/www-data/.composer/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
#22 /home/www-data/.composer/vendor/drush/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#23 /home/www-data/.composer/vendor/drush/drush/drush.php(12): drush_main()
#24 {main}

Tracing through, it appears that the static cache in search_api_get_service_info() isn't being cleared appropriately when a new module's enabled. I was surprised that this wouldn't be more widely reported so tried to create a minimal repro and found that you must have at least one search service enabled already for the problem to show. This seems to be because only in that case does search_api_system_info_alter() populate the search_api_get_service_info() static cache.

It looks like the fix is basically in place in search_api.module:

/**
 * Implements hook_modules_enabled().
 */
function search_api_modules_enabled() {
  // New modules might offer additional item types or service classes,
  // invalidating the cached information.
  drupal_static_reset('search_api_get_item_type_info');
  drupal_static_reset('search_api_get_service_info');
}

But if you look at the stack trace above it's entity_modules_enabled() which triggers the server being saved, so as far as I can tell the Search API hook needs to run before Entity API's. I'm still a bit surprised this hasn't affected more people, so I wonder if I might be missing something (:

Anyway, I've attached a patch which should demonstrate the problem.

Thanks!

And this one seems to fix things for me, thanks.

Oops, short array syntax crept in. Let's try again.

@AndyF backwards compatibility with php 5.3
module_enable(array('search_api_test2'));
Instead of
module_enable(['search_api_test2']

Please also review the rest of the patch for similar array() vs []

Patch needs reroll with recommended changes

Otherwise php 5.4 or higher only

@joseph.olstad Thanks for your feedback - I made those changes in my last comment. I'm a little confused by the latest testbot output and would welcome help interpreting it!

Not sure what to make of the failure:

sudo -u www-data php /var/www/html/scripts/run-tests.sh --list > /var/lib/drupalci/workdir/simpletest_d7/testgroups.txt
PHP Parse error:  syntax error, unexpected '[' in /var/www/html/sites/all/modules/ctools/tests/ctools.test on line 35
Unable to generate test groups

Doesn't seem to be connected with the patch...!

I've attached the full patch without the short array syntax, not sure what testbot will think...

*edit* checked ctools, it passes 5.3 tests
Maybe something missed by ctools tests though.
Meanwhile I queued up php7 test

I recommend the search_api maintainer set the default test to php7

#2942581: ctools.test breaks Feeds tests on PHP 5.3 because of short array syntax

Above issue fixed in ctools dev branch. But not yet released in a tagged release

Thanks for looking into it @joseph.olstad! I've just run the tests locally on 5.3 and they passed, so I'm going to mark it as needs review again.

Passes php 7 tests and I just triggered 5.4

Wow, thanks a lot for all your work there, AndyF! Great job finding out the root cause of this, writing a patch and even providing a proper test – makes it easy to see that there's indeed a problem, and the patch fixes it.
Patch looks great, too, nothing to complain about there either.
So: committed.
Thanks again!

Also, thanks a lot to joseph.olstad for the detective work regarding the mysterious test failure!

Great, thanks!!

@drunken_monkey, please tag and release search_api 7.x-1.23

lots of good quality commits since 7.x-1.22