Static cache of search_api_get_item_type_info() is never cleared

You have a search index on search facets? Seems like a rather weird use case to me …
Anyways, this should of course be fixed, and your solution seems like the best idea. Only flaw is that hook_modules_enabled() and hook_modules_disabled() don't go into the .install file, as far as I know. Also, maybe someone else will want to comment on this.

You have a search index on search facets? Seems like a rather weird use case to me …

No, that's not what's happening. The problem is that if search_api and search_api_facets are enabled in the same request, the new search_api_facet entity registered by search_api_facets doesn't made it to search_api_get_item_type_info() because of the static cache.

As a consequence, search_api_entity_insert() fails when a new facet entity is created.

Note: currently, search_api is processing every entity regardless if it participates in an index or not. Not sure this is actually desirable.

@ #5: Ah, you're right, that is a bit unnecessary (even if it has little impact without the bug). And sadly, the bug could still occur after fixing this, so we'll have to still include the hook_modules_[en/dis]abled() implementation …
Attached patch should fix both issues.

@ jsacksick: Yes, the re-roll was fine, thanks!

Looking at this, is there a reason why search_api_track_item_insert() and search_api_track_item_delete() call the datasource unconditionally, while search_api_track_item_change() only call it when index_directly is FALSE?

Looking at this, is there a reason why search_api_track_item_insert() and search_api_track_item_delete() call the datasource unconditionally, while search_api_track_item_change() only call it when index_directly is FALSE?

Yes, of course. Even if items are indexed directly, their status has to be tracked (since "Index immediately" could be de-activated later, or indexing could fail some time). If we wouldn't notify the datasource of inserts and deletes, the respective items would never be in the tracking table (or stay there forever), and also not marked as dirty later, when "Index immediately" would be deactivated. When the item changes, it is already present in the tracking table, and we don't have to do anything if we index it immediately.

We also shouldn't react to operations on entity types which don't have property information (as we don't provide search integration for those). This should be caught by them not having any indexes anyways, but still better to additionally save the runtime.

@ rgraaf: Both the patch in #7 and this one should work for you (I hope).

Committed. Thanks again for your contribution, jsacksick!

i have the #10 patch applied in a clean commerce kickstart project and i get the same error

just confirming, im also having this issue with a clean kickstart install,

search_api version 7.x-1.7, so the patch doesn't apply here..

SearchApiException: Unknown or invalid item type node. in search_api_get_datasource_controller() (line 1506)

SearchApiException: Unknown or invalid item type profile2

Having the same issue in Search API 1.8 with the Sarnia module.