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>, <term> AND <other-term>, etc.)

    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.
  • The list of Elasticsearch indices fails to load when creating an Elasticsearch index engine

    When creating an App Search engine for an Elasticsearch index in an environment with thousands of Elasticsearch indices, the Select the Elasticsearch index you'd like to use section gets stuck with the "Loading Elasticsearch indices" message. As a result, users are not able to select an Elasticsearch index to complete the creation of the App Search engine.

    This is caused by an outstanding UI bug. To workaround the issue, you can create the Elasticsearch index engine using the API instead:

    POST <enterprise-search-host>:<enterprise-search-port>/api/as/v0/engines/
      "search_index": {
        "index_name": <elasticsearch-index-name>,
        "alias_name": <optional_alias_name>,
        "type": "elasticsearch"
  • Value boosts do not work for number fields on the UI

    Value boosts configured against number fields on the UI do not affect scoring for number fields that are equal to the provided value.

    The workaround is to use the Value Boost API instead of the UI.