Elastic Docs ›
« Configuring encryption keys Troubleshooting »

Known issuesedit

The following known issues affect App Search.

  • The Generate Search Experience functionality does not work with traffic filters.

    Use the following workaround:

    • Clone Search UI repo (React library used to generate the search experience).
    • Rename engine.json.example to engine.json.
    • Update engine.json to point the React app to your Enterprise Search endpoint.
    • Update engine.json to reference your engine’s fields (if not using the sample national-parks engine).
    • Follow the getting started documentation to run the app.

  • App Search users with dev and editor roles do not have access to the App Search web crawler.

    This applies to all versions of App Search.

  • App Search may return unexpected results when using Lucene Boolean search syntax (e.g. <term> OR <other-term>)

    App Search’s relevance tuning can cause logical conflicts with queries that attempt to use Lucene’s Boolean query syntax. This is due to how the underlying Elasticsearch query is crafted for certain relevance tuning settings.

    A workaround is to use the Elasticsearch search API to construct an Elasticsearch DSL request with Boolean logic to App Search.

  • Multi word synonyms are not used in a phrase match, but matched as individual words.

    It is possible for a document that contains the multi word synonym to rank lower than another document that contains the individual terms in a different order.

  • URLs being indexed despite having duplicate content and a canonical URL setting.

    Canonical URL link tags are embedded within HTML source for pages that duplicate the content of other pages. Refer to Manage duplicate document handling for details. The crawler identifies duplicate content by hashing the content of default deduplication fields derived from the page. These fields are defined by the configuration setting crawler.extraction.default_deduplication_fields.

    The web crawler checks your index for an existing document with the same content hash. Users have faced issues where they set canonical link tags for a page that does not have identical content, because the hashes are different. However, upon inspection, the content is the same.

    Use the following workaround:

    You can manage which fields the web crawler uses to create the content hash. If your pages all define canonical URLs, you could safely change your deduplication fields settings to include only the url field. Otherwise, you may need more fields to help check for duplicates. By default, the web crawler checks body_content, headings, links, meta_description, meta_keywords, and title fields.

  • Large document(s) indexed via API don’t appear in the App Search documents UI

    This issue exists because App Search highlighting blocks querying documents containing more than 1M characters. There are two potential workarounds:

    1. Increase the value of max_analyzed_offset in the search query if you’re querying the index directly using Elasticsearch APIs or the App Search Elasticsearch search API.

    2. If you’re querying with App Search, find the underlying index which, has the following pattern .ent-search-engine-documents-{engineName}. Set index.highlight.max_analyzed_offset on the index, by updating the index settings.

      Note the following tradeoffs of increasing the value of max_analyzed_offset:

      • Elasticsearch memory usage and processing time of highlighting will increase.
      • Instead of returning an error on querying, the highlighting will be truncated at the offset limit specified.
« Configuring encryption keys Troubleshooting »