--- title: "Known issues" date: "2024-02-14T06:18:38+00:00" summary: "Explore known issues with Acquia Search, including Solr upgrades, large attachments, and language-specific challenges. Find solutions and workarounds for common problems across Drupal versions and development environments." image: type: "page" url: "/acquia-cloud-platform/known-issues" id: "b2ca2e60-9cf4-4e8e-a4e5-369cb9d95676" --- Table of contents will be added This page describes the known issues with Acquia Search. General issues with Acquia Search --------------------------------- ### 409 Conflict error when deploying Solr 9 configset If you select a Solr 9 configset for an Acquia Search index that is not upgraded to Solr 9, the system returns a `409 Conflict` error. If you switch to a Solr 8 configset after attempting to set Solr 9, the system returns the same error. The system does not update the configset when you select Solr 9 for an index that is not migrated, so the update remains incomplete. This incomplete update causes a conflict when you switch back to Solr 8. _Workaround:_ Select a Solr 7 configset for the affected index. Once the configset is successfully applied, switch back to the Solr 8 configset. ### Internal Solr server error 500: Field indexed without offsets, cannot highlight In Solr versions before Solr 9, the highlighter default was `original`. Starting in Solr 9, the default for `hl.method` is `unified`. _Workaround_: **Option 1:** Update your schema (for example, the `schema_extra_fields.xml` file) and add `termOffsets="true"` and `termPositions="true"` to the dynamic fields in question. Then reindex your content. **Option 2 (simpler, recommended)**: Add or update the `hl.method=original` block in the `solrconfig.xml` file. This block must appear at the top level, as a sibling of ``. original ### Duplicate documents issue with Solr 7 to Solr 8 upgrade If your deployed configsets contain the field, ``, after you upgrade from Solr 7 to Solr 8, a duplicate document issue occurs while indexing. When modifying Drupal content, the system creates a new Solr document and does not update the existing document. For more information about this known issue, see [SOLR-15540](https://issues.apache.org/jira/browse/SOLR-15540). To resolve this issue, Acquia: * Removed the `field name="_root_` from: * [Default configsets](/acquia-cloud-platform/features/acquia-search/getting-started/managing-indexes#create-solr-index) available in the Cloud Platform user interface * All the deployed (“live”) configsets * Removed duplicate documents from the respective indexes. For more information, see [Acquia Search - November 29, 2023](/acquia-cloud-platform/features/acquia-search/release-notes/2023#search-20231129). _Workaround_: If you implemented custom configsets, you must remove the field, `_root_` as follows: 1. Remove the field from configsets by deleting the `` line from existing configsets. 2. Clear the duplicate documents from Drupal and reindex to correct index pollution. Note The `_root_` field is required for nested Solr documents. If the use case requires nested Solr documents, you can re-add this field in a custom configset. ### Solr search has difficulty handling large attachments For more information, see [Issues with large attachments and Solr search](/acquia-cloud-platform/help/93071-issues-large-attachments-and-solr-search "Issues with large attachments and Solr search"). ### Acquia Search can’t be included in a dedicated virtual private cloud Acquia Search is hosted within Acquia’s shared virtual private cloud (VPC). Although you can access Acquia Search from your [Shield](/acquia-cloud-platform/add-ons/shield) applications, the Acquia Search servers are located outside of your Shield dedicated section. Due to the Acquia Search servers’ location, Shield does not protect your search index. For more information about how Acquia uses VPCs, see [Virtual Private Cloud](/acquia-cloud-platform/architecture#cloud-vpc). ### Internal Solr error with Eastern European languages Advanced search functionalities, such as Acquia internal backups and select all queries, may fail if the dynamic field `sort_X3b_*` has class type defined as `solr.ICUCollationField`, and contains unicode characters from Eastern European languages. This will not affect regular indexing and search operations. For more information, see the [Solr ticket](https://issues.apache.org/jira/browse/SOLR-15712). ### Replication issue with the FreeTextLookupFactory class The FreeTextLookupFactory suggester factory class has a known issue wherein the suggester dictionary is not built in all replicas. Therefore, Acquia recommends you to not use the FreeTextLookUpFactory class. Known issues for Acquia Search on Drupal 7 ------------------------------------------ ### The Workbench Moderation module can cause search integration problems For more information about the [Workbench Moderation](https://drupal.org/project/workbench_moderation) module, see its [project page](https://drupal.org/project/workbench_moderation) on Drupal.org. ### Search API has memory errors when indexing For more information about this issue, see [Better memory usage on indexing](https://www.drupal.org/node/1137734) on Drupal.org. ### Search API provides fewer configuration options The Search API module provides fewer configuration options than ApacheSolr integration in Drupal 7. Known issues for Acquia Search on the current Drupal version ------------------------------------------------------------ ### The Search API module can’t display result snippets The Search API module can’t display result snippets—the full node output displays as the search result. _Workaround_: Create a **Search result** view mode to output something smaller than the full node. To add the workaround, complete the following steps: 1. Go to **Structure > Content types > Article > Manage display**. 2. In the **Custom display settings** section, select the **Search result highlighting input** checkbox. 3. Click **Save**. 4. Go to **Structure > Content types > Article > Manage display > Search result highlighting input**. The following settings control each search result’s output. 5. To display result snippets, edit the appropriate field. For example, to make the **Body** field display result snippets, complete the following steps: 1. In **Format**, click **Trimmed**. 2. Click the gear icon. The webpage displays the **Trimmed limit** field. 3. In the **Trimmed limit** field, enter `200` to trim the body field to 200 characters. 4. Click **Update**. You have now configured the **Body** field to display trimmed output as the search result. ### Non-SQL query plugins for Views cause PHP errors For more information about this issue, see [Views problems with non-SQL query plugins](https://www.drupal.org/node/2484565) on Drupal.org. ### Views exposed filters must not be cached Views exposed filters, such as search results and blocks with facets, must not have caching enabled alongside AJAX. For more information, see [Ajax facet block seems to lose views context](https://www.drupal.org/project/facets/issues/2986981) on Drupal.org. ### Content types are unintentionally indexed Acquia Search indexes content types, when that is not the intended behavior. _Workaround_: Add a content type filter to an Acquia Search view. ### Upgrading the search\_api\_solr module from 4.2.x to 4.3.x causes reindexing to fail Upgrading the search_api_solr module from version 4.2.x to 4.3.x results in reindexing failure with the following error: `cannot change field "solr_field_name_here" from index options=DOCS_AND_FREQS_AND_POSITIONS to inconsistent index options=DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS, message: Solr HTTP error: Bad Request (400)` To successfully perform the upgrade: 1. Upgrade the module to version 4.3.x. 2. Delete the index from the Cloud UI. 3. Create a new index using the latest configset applicable to your Solr version. ### Development environments can easily write to production indexes By default, Acquia Search stores configuration in the database. When the production database is pulled into a development environment such as Acquia Cloud IDE or local environment, the Solr core/server, site ID (site\_hash), and other details get copied over. As a result, the development and the production environments end up sharing the same Solr index. This causes numerous issues including duplicate results, results from the wrong site, and deletion of all content in the production environment’s Solr index. _Workaround_: Set the index status to **Read only** on all development environments. 1. Option 1 (works for local development environments and Cloud IDEs): In `sites/default/settings.local.php`, add the following code: // Check if Acquia environment variable is not set or equals 'ide'. if (!isset($_ENV['AH_SITE_ENVIRONMENT']) || $_ENV['AH_SITE_ENVIRONMENT'] === 'ide') { // If there's no 'AH_SITE_ENVIRONMENT' or we are on an Acquia Cloud IDE, // set Acquia Search to read-only mode. $settings['acquia_search']['read_only'] = TRUE; } 2. Option 2: Add additional custom code by following the recommendations in [Read-only Solr search index](https://acquia.my.site.com/s/article/360006769234-Read-only-Solr-search-index). ### Suggester configuration causes the "Lock held by this virtual machine" error The "Lock held by this virtual machine" error occurs in Solr when the following actions take place simultaneously: * Indexing * Building of a suggester for the index This error occurs due to individual folders not being assigned for each suggester in the configuration. Consequently, Solr attempts to build all these dictionaries in the same folder, leading to a write.lock conflict in Solr. This typically happens when Solr is in the process of building these dictionaries.  The configset [release](https://docs.acquia.com/acquia-cloud-platform/features/acquia-search/release-notes), **(Latest) Drupal 8 / 9 - Search API Solr 4.2.0 - Solr 7 - \[drupal-4.2.0-solr-7.x-0\] - v2.0,** provides a fix for the Acquia default configuration. However, if you are using a custom configset that includes a suggesters configuration, you must add the following configuration item to each suggester: ./SUGGESTERS_NAME The following is an example configuration for the `en` suggester: `./en` and `./und`. en AnalyzingInfixLookupFactory DocumentDictionaryFactory twm_suggest text_en sm_context_tags true false ./en